On Fri, Nov 7, 2008 at 11:31 AM, Xavier <shiningxc@gmail.com> wrote:
On Fri, Nov 7, 2008 at 5:52 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Nov 7, 2008 at 2:36 AM, Jatheendra <jatheendra@gmail.com> 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