starred/dotnet-packaging
1
0
Fork 0
mirror of https://github.com/quamotion/dotnet-packaging.git synced 2026-02-16 05:44:46 +00:00
Code Issues 207 Packages Projects Releases Wiki Activity

Debian strech #9

New Issue
Closed
opened 2026-01-29 16:27:06 +00:00 by claunia · 7 comments
claunia commented 2026-01-29 16:27:06 +00:00
Owner
Copy Link

Originally created by @franklupo on GitHub (Oct 13, 2017).

error dependency
e.g depends on libicu52; however

8e191a0637/Packaging.Targets/Deb/DebPackageCreator.cs (L72)

https://github.com/dotnet/dotnet-docker/blob/master/2.0/runtime-deps/stretch/amd64/Dockerfile

Originally created by @franklupo on GitHub (Oct 13, 2017). error dependency e.g depends on libicu52; however https://github.com/qmfrederik/dotnet-packaging/blob/8e191a06370adf05f0bc15f783e8cf1d726d9509/Packaging.Targets/Deb/DebPackageCreator.cs#L72 https://github.com/dotnet/dotnet-docker/blob/master/2.0/runtime-deps/stretch/amd64/Dockerfile
claunia commented 2026-01-29 16:27:07 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 14, 2017):

@franklupo Thanks for reporting this! Yes, different versions of Debian & Ubuntu ship with different versions of libicu so we'll need to detect this when creating the .deb package.

I'm thinking it may make sense for us to do the following:

  • Populate the list of dependencies in a property or item (say, DotNetDependencies or something similar) in the .targets file depending on value of the TargetRuntime property.
  • We could allow users to override this property (for example, Debian variants we didn't think of, newer versions of Debian/Ubuntu which we don't yet support,...)
  • This property/item could be passed to the task that generates the .deb packages.

@kekekeks thoughts?

@qmfrederik commented on GitHub (Oct 14, 2017): @franklupo Thanks for reporting this! Yes, different versions of Debian & Ubuntu ship with different versions of `libicu` so we'll need to detect this when creating the .deb package. I'm thinking it may make sense for us to do the following: - Populate the list of dependencies in a property or item (say, `DotNetDependencies` or something similar) in the `.targets` file depending on value of the `TargetRuntime` property. - We could allow users to override this property (for example, Debian variants we didn't think of, newer versions of Debian/Ubuntu which we don't yet support,...) - This property/item could be passed to the task that generates the .deb packages. @kekekeks thoughts?
claunia commented 2026-01-29 16:27:07 +00:00
Author
Owner
Copy Link

@kekekeks commented on GitHub (Oct 14, 2017):

I guess we could set dependency alternatives for libicu. It would look like libicu52 | libicu57 in Depends line of the control file.

@kekekeks commented on GitHub (Oct 14, 2017): I guess we could set dependency alternatives for `libicu`. It would look like `libicu52 | libicu57` in `Depends` line of the control file.
claunia commented 2026-01-29 16:27:08 +00:00
Author
Owner
Copy Link

@kekekeks commented on GitHub (Oct 14, 2017):

See https://www.debian.org/doc/debian-policy/#document-ch-relationships

In the Depends, Recommends, Suggests, Pre-Depends, Build-Depends, Build-Depends-Indep and Build-Depends-Arch control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols |. In such a case, that part of the dependency can be satisfied by any one of the alternative packages.

@kekekeks commented on GitHub (Oct 14, 2017): See https://www.debian.org/doc/debian-policy/#document-ch-relationships >In the `Depends`, `Recommends`, `Suggests`, `Pre-Depends`, `Build-Depends`, `Build-Depends-Indep` and `Build-Depends-Arch` control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols `|`. In such a case, that part of the dependency can be satisfied by any one of the alternative packages.
claunia commented 2026-01-29 16:27:09 +00:00
Author
Owner
Copy Link

@kekekeks commented on GitHub (Oct 14, 2017):

We could also add SkipDefaultDebianDependencies property and let dependencies to be populated via DebDependency item.

@kekekeks commented on GitHub (Oct 14, 2017): We could also add `SkipDefaultDebianDependencies` property and let dependencies to be populated via `DebDependency` item.
claunia commented 2026-01-29 16:27:09 +00:00
Author
Owner
Copy Link

@qmfrederik commented on GitHub (Oct 14, 2017):

@kekekeks Using dependency alternatives definitively sounds like the easier thing to do.

I think it'd be a good idea to allow the user to override the default dependencies.

Perhaps we can just define the dependencies in the DebDependency variable in the .targets file and pass them to the task, and set the DebDependency variable if it is empty (that we we can avoid the SkipDefaultDebianDependencies variable)?

@qmfrederik commented on GitHub (Oct 14, 2017): @kekekeks Using dependency alternatives definitively sounds like the easier thing to do. I think it'd be a good idea to allow the user to override the default dependencies. Perhaps we can just define the dependencies in the `DebDependency` variable in the `.targets` file and pass them to the task, and set the `DebDependency` variable if it is empty (that we we can avoid the `SkipDefaultDebianDependencies` variable)?
claunia commented 2026-01-29 16:27:10 +00:00
Author
Owner
Copy Link

@kekekeks commented on GitHub (Oct 14, 2017):

Right now DebDependency is used as MSBuild item name for adding extra dependencies, see
https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/DebTask.cs#L56
https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/DebTask.cs#L110

They get added later here: https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/Deb/DebPackageCreator.cs#L76

So we either need to use SkipDefaultDebianDependencies or support package alternatives in DebDependency item via something like

<DebDependencyWithAlternatives>
    <DebDependency Name="libicu52"/>
    <DebDependency Name="libicu57"/>
</DebDependencyWithAlternatives>

The problem with this approach is that we won't be able to use Include from msbuild

@kekekeks commented on GitHub (Oct 14, 2017): Right now `DebDependency` is used as MSBuild item name for adding extra dependencies, see https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/DebTask.cs#L56 https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/DebTask.cs#L110 They get added later here: https://github.com/qmfrederik/dotnet-packaging/blob/master/Packaging.Targets/Deb/DebPackageCreator.cs#L76 So we either need to use `SkipDefaultDebianDependencies` or support package alternatives in `DebDependency` item via something like ```xml <DebDependencyWithAlternatives> <DebDependency Name="libicu52"/> <DebDependency Name="libicu57"/> </DebDependencyWithAlternatives> ``` The problem with this approach is that we won't be able to use `Include` from msbuild
claunia commented 2026-01-29 16:27:10 +00:00
Author
Owner
Copy Link

@franklupo commented on GitHub (Oct 14, 2017):

Good idea

Best regards

@franklupo commented on GitHub (Oct 14, 2017): Good idea Best regards
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pending-validation
pull-request
Mirrored from GitHub Pull Request
 up-for-grabs
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#9
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?