Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a): > On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler <kevin.kof...@chello.at> wrote: >> Raphael Groner wrote: >> >>> Kevin, >>>> * that no package may ever be module-only, but >>>> modules can only be used for non-default >>>> versions. >>> That statement doesn't make any sense for me. Can you explain, please? How >>> should modules live without packages in background? We'd already discussed >>> this in another thread. >> I don't think you understood the sentence I wrote. >> >> The current state is that we can have: >> main repo: no package foo, no package libfoo (but many other packages) >> module foo-1: foo-1.8.10, libfoo-1.8.12 >> module foo-2: foo-2.0.0, libfoo-2.0.1 >> but the "main repo: no package foo, no package libfoo" part is what I am >> objecting to, especially if libfoo is used by more packages than just foo. >> >> I want to require the main repo to contain some version of libfoo, and other >> packages (from the main repo or from modules other than foo) should be >> required to use the version in the main repo and not in some non-default >> module. > This is literally the exact way things work today, except that instead > of "the main repo", we treat it as "the main repo OR the default > stream of the module". > > Nothing in the main repo is permitted to use anything that is not > available in the main repo or a default module stream at runtime. Full > stop. > > The case of Ursa Major is special: it's addressing the case where we > may have some *build-time* requirements that are not in the default > repo.
I might be missing something, but how do you want to enforce this ^^? This sounds that although build succeeds, runtime might fail later, because of missing dependencies. This might not happen for Go you used as an example, because it is statically linked, but it must be the case for other dynamically linked libraries. V. > All of their runtime requirements must still meet the above > criteria, but perhaps their build requires a too-new (or > old-and-more-stable) build-time requirement. In this case, it is far > easier on the packager to be able for them to be allowed to use that > other version to build. > > Consider the Go case: we know that most Go packages will be statically > linked (issues with that are a different topic), so we know they will > work fine once built. However, if the application upstream cannot > build with the latest "stable" version because of > backwards-incompatible changes, it seems to me that it's perfectly > reasonable to allow them to use a slightly older Go compiler from a > module stream. Strictly speaking, this is no different from offering > an SCL or a compat-* package of the compiler, except that having it as > a module means that its executables and other tools will be in > standard locations, so the build process doesn't need to be patched to > locate them elsewhere. > > >> Though I think that ideally, we would have only the main repo and pick one >> version of foo to ship there instead of offloading this distribution job to >> the user through arbitrarily-branched modules. >> > And if we lived in a proprietary world where we had dictatorial > control over what our users are allowed to install, that might work. > In 1998, this approach made sense. At that time, your two choices for > any software were "install a distro package" or "try to compile it > yourself". Upstream projects themselves used to strive to build > packages for the distros so they could make sure they reached users. > That is simply not how much of today's software works and on the rare > cases they *do* provide a distro package, it's usually for the distros > with a (real or perceived) long-term stability guarantee. > > What we are doing is providing additional tools. If you do not wish to > use them to build your packages, don't! That's fine. For others, it's > a matter of putting a price on their time: is it worth spending an > extra two months hacking on a package in the name of ideological > purity, or is that two months better spent doing other work? The > Fedora of a few years ago would have *required* the former approach. > Fedora today is more welcoming. > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
