Skip to content

The official build doesn't produce Crossgen2 pack RPM or Debian packages #1985

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

Closed
dagood opened this issue Jan 21, 2020 · 5 comments
Closed
Assignees
Labels
area-Infrastructure-installer untriaged New issue has not been triaged by the area owner

Comments

@dagood
Copy link
Member

dagood commented Jan 21, 2020

The official build produces e.g. dotnet-crossgen2-pack-5.0.0-alpha.1.20071.1-win-x64.msi, but no corresponding dotnet-crossgen2-pack-5.0.0-alpha.1.20071.1-win-x64.rpm or .deb for use on Linux. These are required for the SDK to incorporate them properly--I think not having them will make it harder to integrate SDK support.

I'm taking a look, I would expect these to be created.

/cc @fadimounir @dotnet/crossgen-contrib

@dagood dagood self-assigned this Jan 21, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Jan 21, 2020
@dagood
Copy link
Member Author

dagood commented Jan 21, 2020

I think it's because of this line:

<BuildOnUnknownPlatforms>false</BuildOnUnknownPlatforms>

The Debian package production step runs as ubuntu.14.04, which isn't in the list of valid RIDs. Same for rhel.7 and RPMs.

I think a simple fix would be to add ubuntu.14.04 and rhel.7 to the list of RIDs in that file. That doesn't really represent what's going on, though--we're actually packaging up linux bits.

I'm going to try using a target to manipulate the process instead, and have it condition based on InstallerSourceOSPlatformConfig = linux-x64.Release passed in during lab builds. That's the RID that actually matches up with the content here.

@jkotas
Copy link
Member

jkotas commented Jan 21, 2020

.msi

Does it mean that I need to be an admin to install crossgen2?

I though that crossgen2 is going to be a nuget package, and you will acquire it by adding a nuget package reference somewhere.

@dagood
Copy link
Member Author

dagood commented Jan 21, 2020

It's both, the .msi is there so that it can be chained into the SDK Windows installer. Similar for Deb/RPM, they require admin to install, but can be depended on by the SDK RPM/Debs. If the user doesn't install it through these methods, it'll be acquired from nuget.org. (From some .NET 5 dev feed prior to release.)

We may decide not to include the crossgen2 pack in any SDK installation method, like runtime packs. Didn't actually consider that before... I don't object to doing a little work now to keep it unblocked though.

@jkotas
Copy link
Member

jkotas commented Jan 21, 2020

I think the only packaging for crossgen2 we need to worry about is nuget. .msi/.rpm./.deb does not matter for foreseeable future or ever.

@dagood
Copy link
Member Author

dagood commented Jan 21, 2020

Ok, thanks. It makes sense to me for this to be similar to the runtime packs in that way. I'll go ahead and close and note that on #1867.

@dagood dagood closed this as completed Jan 21, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Infrastructure-installer untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

3 participants