Duncan wrote: > William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted: > > >> On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote: >> >>> We also need to consider whether people even want it done exactly the >>> way Portage does it now. Some developers have expressed a preference >>> for a package.mask.d of some kind instead. >>> >> I saw that, and I'm not sure why they suggested changing the directory >> from package.mask to package.mask.d, since all you would need to do is >> rename the file package.mask to something like package.mask/oldmasks and >> the masks in it would be preserved until you put them in different files >> in the package.mask directory and removed them from oldmasks, ultimately >> deleting oldmasks. >> > > The (one) idea is to keep package.mask as a file for old package managers > that don't know about package.* as a directory yet. Moving package.mask > (the file) to package.mask/oldmasks wouldn't accomplish that. The > scenario people are worried about, is where (for example) someone has > gone away for their year's service (or two, or whatever) that some > nations have, and comes back and tries to upgrade, only to find the tree > is so changed that as soon as they sync, their old package manager is > broken, to the point they can't use use it to upgrade to a new version, > in ordered to be able to upgrade everything else! > > Actually splitting the current single file into multiple files isn't > really a problem, and would probably be done at the same time package.mask > (.d) is made a directory, all in the same commit, so it's nothing to > worry about. > > That said, in this particular instance, I don't believe that should be a > big problem. Why? Because portage has supported it for years already, > and anyone using a PM that doesn't currently support it has by definition > already demonstrated they are reasonably active about their Gentoo based > system management choices, and thus isn't likely to let a system go > unsynced and the PM unupdated for greater than say 90 days anyway. Thus, > when the policy is approved by council, stick a 90-180 day hold on > changing old profiles in the tree, and be done with it. > > So ancient PMs shouldn't be a problem either way, here. Which leaves > only a simple bikeshedding issue, whether people prefer keeping the names > we have, or switching to the *.d forms in keeping with the pattern used > for all those /etc/*.d directories, of which a quick ls here demonstrated > there's about double the number I expected, having never actually counted > them before. While I'd vote for sticking with what we have, that /is/ > just bikeshedding, and I REALLY want to just get on with it, regardless > of what it's named, as the feature really is quite useful. > >
While I like your example, if this were to happen and a couple other things has been updated, like for example expat a while back and other similar update nightmares, wouldn't a reinstall be easier and most likely recommended anyway? I have seen this recommended and even made that recommendation on -user a few times. I would also do a reinstall on my own system if I had been gone for 6 months or more. With the updates coming pretty fast for most things, you would most likely recompile most everything on the system anyway. Save the configs and the world file and just start over from a very fresh stage tarball. It is good to look out for those braves souls that would try to update anyway but thought it worth a mention. Would upgrading be recommended? < back to my hole > Dale :-) :-)
