-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Creates a single package for Windows #4540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a77f135 to
7495e9a
Compare
build.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused by the reuse of the name Runtime - Now in Start-PSBuild it is used as "Generic" runtime. Here as "minimal level" runtime. I believe we should rename first or second.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is consistent with dotnet's portable runtime concept. unfortunately, they have defined the portable runtimeid for windows to be win7-x86 and win7-x64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iSazonov we have to use win7-* to make sure the package works on all supported Windows OS versions. It would be weird for cmdline usage to specify win7-x86 or win7-x64, hence I changed it to win-x64 and win-x86. The script changes it to win7-*.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that the variable name "Runtime" accept different values 'win-x64' -> 'win7-x64' , 'win-x86' -> 'win7-x86' - Can we use win7-* with Start-PSBuild?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adityapatwardhan I think I agree, How about we make the RID you use win7-* and translate the suffix to win-* in the packaging module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My feedback here was that it's better for transparency's sake that we use the same RIDs as dotnet-cli as opposed to doing black magic over their unfortunate naming. Anyone poking into RID documentation will just be confused if we try to normalize away the 7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had the same opinion as @TravisEz13 on the package naming, though. 👍
build.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the RIDs in New-PSOption should be consistent with Start-PSBuild
|
@joeyaiello @TravisEz13 @iSazonov Thanks for the feedback. To summarize, keep the value for -Runtime as win7-x86 and win7-x64 and remove other win* values. During packaging change the package name to win-x86 and win-x64. I will update PR soon. |
7495e9a to
6b6cc78
Compare
|
@TravisEz13 @iSazonov @joeyaiello I have updated the PR. Please have a look. |
build.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dotnet --info returns win10-64 for me - we need to add a convertion here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have 2 options, first do the conversion here. Other is to make runtime parameter mandatory. I prefer the first one. So if user does not specify -runtime we auto-select win7-x86/x64 on windows. On Linux/Mac, we don't change anything. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have an Issue to make a single package for Linux too and seems the same problem too. So I believe we should use the same logic for both.
If we continue to use dotnet --info we could move the logic in separate function for Windows and Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, Linux will require two packages because of packaging format differences (RPM vs DEB).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TravisEz13 which of the two options you prefer?
- Do the conversion from Win10-x64 -> Win7-x64 in build.psm1
- Make -Runtime a mandatory parameter.
build.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though win81-x64 and win10-x64 are removed from this list, when running Start-PSBuild we will still see the publish folder path is netcoreapp2.0\win10-x64\ on a win10 machines and netcoreapp2.0\win81-x64\ on a win81 machine. However, we are not allowed to specify win10-x64 or win81-x64 for the -Runtime parameter here. The user experience seems broken to me.
My opinion is to keep Start-PSBuild and New-PSOptions unchanged, and only make some changes to the packaging scripts. After all, we only care about win7-* RID when doing the universal packaging for windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this suggestion. I will make the updates.
docs/maintainers/releasing.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Windows, the
-Runtimeparameter should be specified forStart-PSBuildto indicate what version of OS the build is targeting.
This sentence needs to be updated to explain that -Runtime needs to be win7-* to build windows universal package.
Build for v6.0.0-beta.1 release targeting Windows
Here we still should mention that targeting Windows 7.
tools/packaging/packaging.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two new lines here. Maybe one would be sufficient.
docs/maintainers/releasing.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this should be updated to Create Windows universal packages for v6.0.0-beta.1 release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dotnet uses the term portable instead of universal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe portable is used for cross platform, this is universal across all windows versions.
6b6cc78 to
bb36145
Compare
bdf3d88 to
6258b37
Compare
.spelling
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo?
tools/packaging/packaging.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add
[ValidateScript({!$Environment.IsWindows})]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot add this, as it is valid for Windows and Non-windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Closed.
tools/packaging/packaging.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe move to Line 37?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
6258b37 to
aa14847
Compare
|
@daxian-dbw @TravisEz13 @iSazonov @joeyaiello Please have a look. All feedback is addressed. |
|
No new ideas yet :-) |
tools/packaging/packaging.psm1
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we package x86 now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, I forgot that we are doing cross compilation so the actual RID will still be *-x64.
@adityapatwardhan and I just talked and agreed that we should bring back the WindowsRutnime parameter here. And that parameter probably should be made mandatory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you make it mandatory? What happens when you are producing a deb, pkg, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Travis is correct, we cannot make it mandatory.
Changes to packaging.psm1 to create a single package to work on all versions of Windows. The runtime used is win7-x86/x64. The package that is created has a name suffix win-x64 or win-x86 to signify it works on any version on Windows.
9bcce95 to
a838db6
Compare
|
We will have the |
|
I agree, this should be merged after the release. We do not have the ability to test a package in an automated way. We should get that working first.
Get Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: Dongbo Wang <notifications@github.com>
Sent: Tuesday, August 22, 2017 9:39:54 AM
To: PowerShell/PowerShell
Cc: Aditya Patwardhan; Mention
Subject: Re: [PowerShell/PowerShell] Creates a single package for Windows (#4540)
We will have the beta-6 release on this Thursday (8/24), and we don't have enough time to stabilize this change. Travis and I chatted offline and agreed that we should hold off this change till after this release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F4540%23issuecomment-324083453&data=02%7C01%7Cadityap%40microsoft.com%7Cdcfeca2cbbde41e722e908d4e97c6b24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636390167972135774&sdata=GcVq9IzmSrapBfddMHIUl7wg3KOnWvWTRDdcsL3i0dQ%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMOhvRZqIxURR3aQjRDHbIGQeoyz9GjNks5sawRZgaJpZM4Oyyz4&data=02%7C01%7Cadityap%40microsoft.com%7Cdcfeca2cbbde41e722e908d4e97c6b24%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636390167972135774&sdata=RhRENrF%2F95PZIs%2FYdAEZFCxEe2pfLuZ09MvHR7c20gc%3D&reserved=0>.
|
|
There is some logic in the MSI package that seems to check the Windows C Runtime and VS Studio 2015 C++ redistributables are present and return error message if not (see (54e892a)). It seems this logic is enabled in downlevel MSI package (@mirichmo please correct me if I'm wrong). I bring this up because this caused an issue that causes Win81 packages fail to install on Server2012R2. I'm not sure if this will have any impact when running win7 MSI packages on Win10/Server2016. |
|
I filed #4665 to cover the installer issue. The check needs to be more generic to cover the scenario where the dependencies are installed via Windows Update |
|
@TravisEz13 I have merged this PR. Do you think any other scripts need to be changed accordingly? (e.g. powershell/psrelease ??) |
|
@daxian-dbw I'll look at the builds tomorrow and see if everything went correctly. |
The updates to build.psm1 and packaging.psm1 create a single package (per bitness), which works on all the Windows OS versions, namely Windows 7 / Windows Server 2008 R2, Windows 8.1 / Windows Server 2012 R2, Windows 10 / Windows Server 2016.
[daxian edited] This PR has been approved by @TravisEz13 and @iSazonov, so I merged it.
Fixes #4315 and #2608