On Fri, Nov 7, 2008 at 11:31 AM, Xavier <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 5:52 PM, Aaron Griffin <[EMAIL PROTECTED]> wrote: >> On Fri, Nov 7, 2008 at 2:36 AM, Jatheendra <[EMAIL PROTECTED]> wrote: >>> Hi all, >>> Im trying to add some downgradability magic into pacman .Being quite >>> new to pacman code, i need your help to identify the possible >>> pitfalls of my approach before trying something. >>> >>> What i plan to do is.. >>> >>> In libalpm/remove.c unlink_file() [ I guess remove.c is the only >>> place where we are removing files ] >>> >>> replace all unlink(), rename() etc with copyandunlink , copyandrename >>> etc which will copy the file first into an archive file >>> package-backup.tgs in cache,then do unlink or rename. Then finally >>> include all the necessary .INSTALL ,PKGINFO ,.CHANGELOG etc and clean >>> up. >>> >>> So even if i do a -Scc i will have a backup of what was installed on >>> my system and can roll back to the previous state. >> >> I, for one, like this idea. Not that I'd personally use it too often, >> but the concept seems useful. It gives us coverage for all the "give >> us a backup kernel!" ideas. > > For this coverage, it seems fine (maybe even better?) to have it > manually triggered rather than automatically done for every single > packages. > > Then it is the same as bacman external script : >> bacman -h > This program recreates a package using pacman's db and system files > Usage: bacman <installed package name> > Example: bacman kernel26 > > instead that we are trying to make it more complex by integrating it > into pacman directly. > > And again, if it is automatically done for every single packages, then > what is the difference with never running -Scc?
I 100% agree with Xavier here. This seems to be an overcomplex solution to a problem that I'm not sure really exists. If people really want backups, either use -Sc instead of -Scc, have another package backup directory that you copy these essential packages into, or use the existing bacman script. pacman is a package manager, not a system recovery tool. -Dan _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
