Re: Ursa Major (modules in buildroot) enablement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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. 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux