El jue, 08-03-2018 a las 12:55 +0200, Panu Matilainen escribió: > On 03/08/2018 12:42 PM, Panu Matilainen wrote: > > On 03/08/2018 12:21 PM, Reindl Harald wrote: > > > > > > > > > Am 08.03.2018 um 08:53 schrieb Panu Matilainen: > > > > P.P.S. So why didn't yum have anything like that? Because back > > > > then, > > > > there were other upgrade methods that did run on the "target > > > > stack": > > > > anaconda, preupgrade, fedup to name a few > > > > > > and i never used one of them - i did hundrets of dist-upgrades > > > for > > > more than a decade on dozens of machines (workstations and > > > production > > > servers) with yum/dnf - full stop > > > > Sure. You just either didn't upgrade between versions that > > introduced a > > new rpmlib() dependency or updated rpm first, one way or the > > other. > > ...or the couple of features were introduced in that period were > done > using the one generic solution at hand I did mention in my earlier > email: wait until the previous Fedora supports the new feature too > before enabling in the new. Come to think of it, I think this was > mostly > the case. It'd be in the ml archives if somebody wants to dig (we're > talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload > compression being the big ones I can remember offhand) > > Oh, and of course back then it was nearly impossible to introduce > such > features in the first place because the builders were running RHEL. > Those couple of features that were introduced required a custom rpm > to > be used on builders. Those were the days... no I dont miss. > I do not miss those days either, but we knew and communicated the changes. and managed them so upgrades would work. We were careful to make sure that the change was managed. Maybe too careful. Managing hybrid systems for building was a pain and I never want to go do that again. We do need to make sure that as new rpm/dnf features are supported that we have everything in place to fully support them, that means waiting for a short period of time from being in RPM to being something we can tell packagers to go and use. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
