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@xxxxxxxxxx> 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? Zbyszek _______________________________________________ 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
