On Mon, Aug 24, 2020 at 09:02:55AM -0400, Stephen Gallagher wrote: > 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. We use fedora-obsolete-packages to remove packages from end-user systems. Users can opt-out of installation of fedora-obsolete-packages and retain packages that would be obsoleted [*]. The same mechanism could be used RHEL, for example by having 'rhel-is-up-to-date.rpm' installed by default, with newer versions doing the obsoletes for packages that have been dropped. Users *may* stop the upgrade of rhel-is-up-to-date, but then they know their system is using outdated packages. DNF will even nicely tell them which ones. This is: a) simple, b) well-understood, c) already implemented. Zbyszek [*] Right now fedora-obsolete-packages has Provides:libsolv-self-destruct-pkg(), so this muddies the situation a bit. Let's assume that the packages in RHEL would not have that set. _______________________________________________ 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
