On Mon, Dec 2, 2019, 04:43 Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
Igor Gnatenko wrote:
> 1. Do we want to package multiple streams only for "leaf" software or
> any kind of it?
> I believe that we need both, and we do support both. However, it might
> not look as nice as it could:
> * Need to create multiple repos for different "streams"
> * Need to maintain epel7/epel8/f30/f31/master branches
> * Package names have to be "mangled" (e.g. mozjs38, mozjs60) and it is
> manual work
Your proposal addresses these, but skips the same requirement the current
Modularity also fails to address by design, i.e.:
> * However, those are supposed to be (according to the guidelines)
> parallel-installable (and not be conflicting in any way)
In particular, your proposal suggests:
> * Packages produced from nodejs.src have Provides: stream(nodejs)
> stream(nodejs:9) and Conflicts: stream(nodejs) so that it is
> explicitly not possible to install 9 and 10 at the same time
which explicitly excludes the parallel installability. So I do not see how
it addresses the main drawback Modularity has compared to compatibility
packages.
(Note: The sentence as stated also means that the package Conflicts with
itself, which will probably also badly confuse some tools, but that is a
technical detail that should be fixable. It is the underlying concept of
Conflicting with all other versions that is the real issue.)
Your proposal is essentially a proposal to automate the creation of
versioned (with suffixed Name) compatibility packages, but it excludes the
most essential part of the compatibility package pattern, the one that makes
it suited for this use case unlike the current Modularity. So I fail to see
how it addresses in any way the issues we are having with the current
Modularity.
Oh yeah, this is not only the thing I'm proposing. People want to have "stream branch" and build from it to all Fedora and EPEL and I thought that it was clear however it was not. Basically part of the proposal is to have let's say branches by major version which builds into all releases.
You suggest to change the packaging guidelines to match the technical
limitations of your proposed technology:
> * Packaging guidelines should be adopted to accept conflicting
> packages and tooling should be improved to show the conflicts and how
> to resolve them
but the guideline that compatibility packages should not conflict exists for
a strong reason, and removing the guideline will not make the issues that
lead to its existence magically go away.
Non-default versions of non-leaf packages MUST be parallel installable with
the default version for the distribution to be consistent and for users to
be allowed to freely choose their applications without arbitrary conflicts.
Otherwise (i.e., if parallel installability is not implemented), what you
write:
> Using some examples from previous threads, why does bugzilla have to be
> built against 2 different versions of perl and users could choose? I think
> maintainer should choose one version of perl and let bugzilla use it.
is just not true. If the 2 different versions of Perl cannot coexist,
building Bugzilla against only one version is not possible without making
Bugzilla incompatible with anything built against the other version.
I agree that we should only build each package against one version of Perl
(the distribution default wherever possible, otherwise the most suitable
version), but that requires that the users can actually install more than
one version at the same time.
But going back to your questions and answers:
> 2. Do we want to support buildtime-only packages?
> I would rather generalize this category as "less-supported packages".
This is getting dangerously close to the strawman antipattern: you are
modifying the question before answering it. That said, you then add:
> Obviously, for packages which are used in runtime need a proper
> support as we do today for all packages to share work
which limits the scope to build-time-only packages again. So why did you
attempt to modify it above?
> I maintain 800+ Rust packages and very often I need to update them to
> an incompatible version. In Rawhide I just do it, update all dependent
> packages to use new version, and if I can't do that for some reason,
> create "compat" package. Obviously, all patches are sent to the
> upstream.
> Upstreams are removing features, I need to deal with Obsoletes but I
> simply can't continuously add new Obsoletes into the
> fedora-obsolete-packages.
It is a common misconception that any package removed from Fedora belongs
into fedora-obsolete-packages. In most cases, you should actually NOT add
the package there. Just stop shipping it. If the user has an obsolete
package installed, it should be kept by default. Only if it actually causes
file conflicts with current software, it makes sense to Obsolete the package
at RPM level. (Arguably also for dependency conflicts, but those can
actually be resolved with the DNF --allowremove flag, so it is not that
clear cut. I would argue for keeping the packages by default and letting the
users remove obsolete packages with broken dependencies manually.) We should
not remove software that users may still be using from users' systems for no
good reason. Especially not if it causes extra work for you as the
maintainer.
> And what for if they are used only during build of other, more important,
> packages? Why do I have to spend time with upgradepaths?
Because the user may want to use that dependency to either rebuild your
package (which is definitely a valid use case in a Free Software
distribution), or to compile some other software (something we definitely
also want to support), or to develop some new software (which is explicitly
one of the target user bases of Fedora Workstation), or even for something
entirely different (which might not be possible for a Rust library, but
think, e.g., of some LaTeX package that your package needs to compile its
documentation, but that can also be used to write documents entirely
unrelated to software).
If you are spending your time to get the dependency into Fedora because your
package needs it, you should also take the little extra time it takes to
support it properly.
> I definitely want some mechanism which will tell to user that "THIS
> PACKAGE IS NOT FULLY SUPPORTED."
And I think telling that to the user is absolutely unfair and against the
spirit of Fedora.
> Obviously, for packages which are used in runtime need a proper
> support as we do today for all packages to share work (that's the
> place where I agree with Kevin Kofler.)
You do not really agree with me because I do not see any valid reason for
making a distinction between build-time and runtime dependencies there. If
your package depends on something, either you or somebody else must maintain
the something in Fedora and it must be available for all users, no matter
how exactly the dependency is used. And all the more so if we are not even
talking about a build-time-only tool, but about statically-linked Rust code
which is actually used at runtime, just not in the form of the package.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
