Marc Paré wrote: > > So, in terms of space used for this, if you had to install all 6, > would this tax the system so much and risk filling up the hardrive > needlessly.
Not really, since the old versions would be removed when the new ones were installed. The behavior I described is not part of the proposal; that's what happens today. > > It not, if a rollback were done, could all 6 as well as the new F be > removed and the old version restored? Yes, that's exactly what happens today.The problem is that today, removing them may cause tons of other packages to have to be removed because they require things that A-F provide. This wasn't a problem on upgrade, because the removal of the old and the addition of the new was a single urpmi "transaction" (I put this in quotes because urpmi uses "transaction" to mean something other than what I mean here), and urpmi "knew" that the new versions supplied all the things that vanished when the old versions were removed. Today, rollbacks have to be done manually - remove new, then install old. Urpmi doesn't know at the time of the removal that you're going to turn around and install the old versions next. It only sees that all the things that both the old and new versions supply are about to disappear from your system, so it tells you that you have to remove any other package which requires those things. > > If this is possible, would this have an impact on devs preparing > Backport versions with rollbacks? RPM dependencies aren't a problem. Urpmi/urpme know all about them. The only packaging changes would be for situations like that where a new version of an application has changed a format of one of its files in your home directory and the new version automatically converts the old version of the file to the new format. In that case, the package would need install scriptlets that copied the old version somewhere so that it could be restored at uninstall time, otherwise the old version of the software won't be able to use the new file format. The biggest chunk of development involved in the proposal is to make urpmi do a rollback as a single operation, just as it does an upgrade. This already exists, in a way; there is a facility called urpmi.recover that does this type of thing. Bit it's not really considered mainstream, and I don't think it's been supported for a while.
