On Mon, Aug 24, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Mon, Aug 24, 2020 at 08:45:49AM -0400, Stephen Gallagher wrote:
> On Fri, Aug 21, 2020 at 1:57 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> >
> > On 21. 08. 20 10:07, Zbigniew Jędrzejewski-Szmek wrote:
> > >> Josh listed some of the key reasons behind default streams: that
> > >> enterprise customers don't like to learn new commands. So default
> > >> streams allowed us to package content with shorter-than-RHEL-lifetime
> > >> and still `yum install foo` would install something the customer
could
> > >> use.
> > > I guess that "shorter-than-RHEL-lifetime" is the big
differentiator, i.e.
> > > normal rpms cannot be yanked from the distribution, but a module can be.
> >
> > Actually AFAIK modules shipped at GA cannot be yanked from the distribution
> > either. Certainly not in Fedora.
>
> That is correct; the modules cannot be removed from the distribution,
> but the encapsulation of them in a separate delivery mechanism enables
> the support *policy* to be different. (In particular, it's acceptable
> from a technical perspective for customers of RHEL to keep using an
> EOL module if they cannot transition in time; they just have to accept
> the risks.)
Well, that confirms what I wrote in the part that was snipped:
> But technically there isn't much difference, and it's only policy that sets
> those two cases apart. So instead of using default modules, why not adjust the
> policy and use non-modular rpms with plain Obsoletes?
>
> (In fact, this simpler approach could be argued to be better, since the technology
> to put Obsoletes in rpms is well established and understood and works nicely, while
> stream Obsoletes are only being conceived.)
I'll ask again: why not?
Well, among other things, RPM-level `Obsoletes:` will remove the
packages from the end-user system, which exactly contradicts what I
just said above.