[pacman-dev] Downgradability...sort of....
Xavier
shiningxc at gmail.com
Fri Nov 7 12:31:30 EST 2008
On Fri, Nov 7, 2008 at 5:52 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Fri, Nov 7, 2008 at 2:36 AM, Jatheendra <jatheendra at 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?
More information about the pacman-dev
mailing list