Hi Kevin, On Mon, Dec 2, 2019 at 4:43 AM 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. Yes, however maintainer of nodejs does not want to rename binaries and patch sources to be parallel-installable. And today, we would block adding such "compat" package into the repositories. I agree it would be nice to have them parallel-installable, but I don't think we need to force it onto all 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. 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. > 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. 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 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). > 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. 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 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? Sorry, it took me quite a while to think about this and write it, so there might be some conflicting points and I might have put something into the places where I should not have done so. > > 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. 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. > > 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). 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. > 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. If somebody gets a package into repo just because he wants to build foo, it is probably not very reasonable to ask them to "properly" maintain it. Otherwise people probably won't upgrade (or package) foo in Fedora and do it in COPR/OBS instead. Which will be definitely even less compliant with our guidelines. I think we get to the point where we need to find balance between "more packages, but less supported" vs "less packages, but with good quality". > > 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. I wanted to point out that you were the most loud about disallowing not shipping packages and that I agree with you that we need to prohibit that, though with some caveats. Sorry if it sounded other way. > 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
