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? _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
