Igor Gnatenko wrote:
> Yes, however maintainer of nodejs does not want to rename binaries and
> patch sources to be parallel-installable.
And that is exactly the problem.
> And today, we would block adding such "compat" package into the
> repositories.
Which is exactly how it should be.
> I agree it would be nice to have them parallel-installable, but I don't
> think we need to force it onto all packages.
But there is actually no way around it because every other approach
inevitably leads to conflicts.
> We have different problems with modularity, like:
>
> * Whole new tooling which has its own inputs/outputs (and many times
> it actually does not work)
> * Overcomplication of dependency solving (even after so many years,
> DNF still can't handle it properly)
> * Different workflow from standard packages which hurts
> discoverability and maintainability (basically it creates small
> distros within one distro)
>
> and many more.
This is true. However, your approach may also introduce this kind of
practical problems. E.g., if you keep the self-conflicting packages.
(For the record, the logically correct way to handle it would be:
Provides: stream(nodejs) = 10
Conflicts: stream(nodejs) < 10
Conflicts: stream(nodejs) > 10
but I disagree with this Conflicts approach to begin with.)
>> 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.
>
> I believe that exactly one of the reasons why Modularity has been
> created. It requires patching of source code and renaming binaries and
> sometimes it is not trivial amount of work.
And this is exactly why I am against Modularity, at least for non-leaf
packages. (And your proposal does not fix this.)
> And at the end of the day, most of the people probably don't need
> installed multiple versions of a package at the same time (e.g. nodejs).
They do if they want to use 2 (or more) applications that happen to depend
on different versions of nodejs (something that is entirely beyond the
user's control) on the same Fedora installation. I think it is entirely
unacceptable to tell users that they cannot install application A and
application B on the same Fedora n installation (even though it might have
worked just fine on Fedora n-1) because A depends on libfoo 2 (or
foo-interpreter 2, this is actually no different) whereas B is stuck on
libfoo 1. (It might have worked just fine on previous releases before the
libfoo 2 stream was added.) The purpose of a distribution is to make
software from different upstreams work together.
>> 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.
>
> Sure, we just have to accept this until perl is made
> parallel-installable. Which may or may not happen, but if I have
> choice between "only one version of perl and no bugzilla" or "two
> conflicting versions of perl and bugzilla using non-default version of
> perl", I will choose latter. Unfortunately reality is not perfect.
I do not see why it would be so hard to provide compatibility Perl versions
in non-conflicting compatibility packages. It has already be done in the
past. It is just a matter of versioning (suffixing) the binaries and the
directories (e.g., /usr/bin/perl5.28, /usr/share/perl5.28/, etc.). The
default version may or may not adopt some of this version-suffixing too. The
only thing that matters is that the non-default versions use it.
> Sure, but let's take specific case. I have had
> rust-smallvec+std-devel-0.6.12-1 which depend on same EVR of
> rust-smallvec-devel. I have updated rust-smallvec-devel to 1.0.0 which
> does not have +std subpackage anymore. On upgrade that causes
> conflicts which can be resolved using --allowerasing --best, but our
> current guidelines say that proper obsoletes must be added somewhere
> so that upgrade works without manual intervention.
In this case, you probably want to add the Obsoletes to rust-smallvec-devel
rather than fedora-obsolete-packages. That avoids all the bureaucracy and is
just one line in the specfile that you need to update anyway.
That said, you may actually need or want to ship parallel-installable
rust-smallvec+std-0.6.12-devel, rust-smallvec-0.6.12-devel, and
rust-smallvec-1.0.0-devel instead (the actual package contents are
inherently parallel-installable anyway!), in which case you don't have to
Obsolete anything, just orphan and stop updating the 0.6.12 ones if you
don't need them any longer.
> I believe I never said to not ship such packages (please correct me if
> I did), we perfectly can ship them to the users, but we need to make
> them aware that maintainer won't be providing proper upgradepath and
> might not fix CVEs in the time manner.
There is no strict guarantee that bugs will be fixed in a timely manner for
ANY package, so there is no point in specifying that explicitly for
individual packages. CVEs SHOULD be fixed ASAP, but that also goes for your
Rust libraries, where in addition you are supposed to rebuild your
statically linked executables ASAP after upgrading the library. If that is
too much work for you, then you should not be packaging statically-linked
software. (And we really need a dynamic linking solution for Go and Rust.
The current approach where libraries are packaged as installed source code
is just not a reasonable approach in a binary distribution.)
For upgrade path for dropped packages, well, either add an Obsoletes
somewhere if it makes sense (as in the example above) or just ignore it.
>> 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 simply can't.
I don't see how it makes so much of a difference in effort.
>> 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.
The part about submitting the build once and having Koji build for all
releases is fine. It has already been proposed by others, and I see no issue
with it (as long as the package is still actually built on each release,
just without the maintainer having to do it explicitly – build once, run
everywhere is not going to work reliably).
It is the automatic suffixing that I have a problem with. I want to see a
separate dist-git module created for the suffixed package instead, where the
specfile is also made conflict-free by the maintainer. In other words, the
good old compatibility package pattern that just works. This part cannot be
reasonably automated, and the part of your proposal that proposes automating
this destroys the most useful part of the pattern.
For the Rust libraries, the automatic suffixing might actually work without
Conflicts, so it could be done there, but not in the general case. Unless
maybe you work with %if conditionals somehow (like the ones we used to keep
the F8 kdelibs.spec in sync with the F9 kdelibs3.spec and the F8
kdelibs4.spec with the F9 kdelibs.spec). Automatically adding Conflicts to
automatically suffixed packages is what I am strongly opposed to. The
automation only makes sense if it can be done without RPM Conflicts and
without file conflicts.
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
