On Mon, Dec 2, 2019, 04:43 Kevin Kofler <kevin.kof...@chello.at> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
