On 7 August 2012 19:52, Michał Górny <mgo...@gentoo.org> wrote: > Hello, > > Right now, every time a bigger bunch of stuff (installed by various > packages) needs to be moved around the filesystem, we have a lot of > work to handle it somehow. And finally, users end up having to either > rebuild a lot of packages to get the files in the new locations, or > we do ugly things to move those files for them. > > I believe we should consider implementing something simpler. Thus, > I propose introducing the following new command to profiles/updates: > > fsmove <old-location> <new-location> > > which -- at the moment of update -- will cause all PM-owned files > in the old-location to be moved to the new one (recursively), updating > the vdb as necessary. > > What remains to be solved/decided: > > 1. How to treat non-owned files? (leave them there, refuse to proceed > with updates?) > > 2. How to handle relevant required updates? (packages which > actually *have* to be updated before moving files) >
I suggest, that due to the volatility of such actions, a user should have to approve each bulk move before it is done, to avoid breaking things. Sort of like etc-update: An update file is added to the repository PMS's detect the new update, and detect the update has not been performed, and starts notifying the user that pending updates are needed. User performs action(s) when ready via some client ( eselect ? PMS specific? ~~ ) Additionally, move batches could have annotations preceding them indicating either instructional ( einfo ) or automated ( like emerge --config ) to handle things like "you'll want to close postgresql before you do this or you'll get database corruption" . I guess what I'm saying basically, is a hybrid concept, sort-of like eselect news , except with executable behaviour attached. At least, thats my 2c. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
