thanks for reaching out.
In general, if a package is versatile enough to support e.g. gtk and qt, it
is good practice to split it into multiple separate projects. See e.g.
lightdm which has e.g. lightdm-greeter-gtk and other greeters.
An example of where the same project can be used in different enough
configurations is grub: in distri, we have grub2 and grub2-efi. Both are
built from the same upstream source, but are different enough that it makes
sense to have two separate packages.
My current take on the subject is that using different package names is
good enough, and keeping variations out of the package manager’s
architecture is a good trade-off.
Hope that makes sense,
On Thu, Sep 26, 2019 at 6:54 AM Liam Wigney <ljdwigney@xxxxxxxxx> wrote:
Distri looks really cool and I've been having some fun playing around with
As someone who comes from using NixOS I do have one big question, is there
any plans for Distri handling variations in package dependency chains when
the package version remains the same?
For example having both package A v1.6 built with clang and gtk as well as
package A v1.6 built with gcc and qt installed at the same time. Or even
just package A can depend on B or C but not both as they have the same roll
but each choice is a trade off in features and/or stability. Currently it
seems there would be a clash in /ro if the usual Distri naming conventions
would be used.
It's quite rare to come up in a distributions actual packaging (I rarely
see it in Nix), however it comes up sometimes when making my own packages
for various reasons. The only real solution I have are that maybe the "less
standard" dependency containing package could add the dependency to their
name, even if some way of dealing with this is adopted by the whole distro
this is what I'll probably do when playing around myself. Adding the whole
dependency chain just isn't viable unless you hash it like Nix but even
that has pitfalls and doesn't seem to fit into the vibe of Distri.
Thanks for all the hard work!