On Mon, Aug 24, 2020 at 8:56 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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@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? Well, among other things, RPM-level `Obsoletes:` will remove the packages from the end-user system, which exactly contradicts what I just said above. _______________________________________________ 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
