[pacman-dev] FS#7308 implementation questions
As I was browsing through the task list I stumbled upon FS#7308. This was a feature I also would like to have implemented so I thought why not try it myself! Because I'm lazy sometimes (who isn't) I don't always take care of any .pacnew or .pacsave files immediately so a nice timestamp suffix would prevent them from getting overwritten by pacman. Especially when you would like to see what changed overtime or when you just don't want that your old saved settings might get overwritten. So this is what i came up with: an AddDateSuffix directive in pacman.conf to enable this behaviour. If the option was enabled by the user add this timestamp suffix -YYYYMMDDHHMM (maybe even seconds??) right after .pac{new,save}. But while while going through some code I noticed the PATH_MAX constant, so can't we get in trouble if this is too small?? Flyspray link: http://bugs.archlinux.org/task/7308 I would really like to get some feedback, Thanks in advance, --DeliQ
On Saturday 25 August 2007 02:08:47 rprinse@planet.nl wrote:
As I was browsing through the task list I stumbled upon FS#7308. This was a feature I also would like to have implemented so I thought why not try it myself!
Because I'm lazy sometimes (who isn't) I don't always take care of any .pacnew or .pacsave files immediately so a nice timestamp suffix would prevent them from getting overwritten by pacman. Especially when you would like to see what changed overtime or when you just don't want that your old saved settings might get overwritten.
So this is what i came up with: an AddDateSuffix directive in pacman.conf to enable this behaviour. If the option was enabled by the user add this timestamp suffix -YYYYMMDDHHMM (maybe even seconds??) right after .pac{new,save}. But while while going through some code I noticed the PATH_MAX constant, so can't we get in trouble if this is too small??
Flyspray link: http://bugs.archlinux.org/task/7308
I would really like to get some feedback,
Thanks in advance,
--DeliQ
Sorry for not wrapping my text at 80 chars. I guess I am a mailing-list newbie;) Anyway, here I have a little C program to test/demonstrate the feature. Is this the correct way for doing this? #include <stdio.h> #include <limits.h> /* PATH_MAX */ #include <string.h> /* memset */ #include <time.h> int main() { time_t rawtime; struct tm *timeinfo; char buffer[12]; char filename[PATH_MAX]; char newpath[PATH_MAX]; time(&rawtime); timeinfo = localtime(&rawtime); strftime(buffer, 12, "%y%m%d%H%M", timeinfo); memset(filename, 0, PATH_MAX); snprintf(filename, PATH_MAX, "%s", "pacman.conf"); snprintf(newpath, PATH_MAX, "%s.pacsave.%s", filename, buffer); printf("newpath: %s\n", newpath); return 0; } AddDateSuffix is a little odd, especially in lowercase (adddatesuffix, mind the 3 d's in a row), so maybe something like AddTimestampSuffix or AddTimeStamp, etc. is better. Suggestions are still very welcome! Thanks in advance, --DeliQ
On Sat, Aug 25, 2007 at 02:08:47AM +0200, rprinse@planet.nl wrote:
As I was browsing through the task list I stumbled upon FS#7308. This was a feature I also would like to have implemented so I thought why not try it myself!
Because I'm lazy sometimes (who isn't) I don't always take care of any .pacnew or .pacsave files immediately so a nice timestamp suffix would prevent them from getting overwritten by pacman. Especially when you would like to see what changed overtime or when you just don't want that your old saved settings might get overwritten.
If pacnew files are overwritten, then it's good, isn't it ? That way, you just have the last one. And for pacsave files, pacman should only save configs as .pacsave when they have been modified, so it'll just keep the most recent one. I think the way it works currently is much better, but well, if it's an option and others find it useful, then why not.
On Saturday 25 August 2007 11:33:46 Xavier wrote:
On Sat, Aug 25, 2007 at 02:08:47AM +0200, rprinse@planet.nl wrote:
As I was browsing through the task list I stumbled upon FS#7308. This was a feature I also would like to have implemented so I thought why not try it myself!
Because I'm lazy sometimes (who isn't) I don't always take care of any .pacnew or .pacsave files immediately so a nice timestamp suffix would prevent them from getting overwritten by pacman. Especially when you would like to see what changed overtime or when you just don't want that your old saved settings might get overwritten.
If pacnew files are overwritten, then it's good, isn't it ? That way, you just have the last one.
And for pacsave files, pacman should only save configs as .pacsave when they have been modified, so it'll just keep the most recent one. Ahh I wasn't aware of that, I'm sorry, you're right.
I think the way it works currently is much better, but well, if it's an option and others find it useful, then why not.
Sure offcourse, I guess I saw it as a nice oppurtunity to get to know the pacman source code and do something back. Maybe if other people want this as well I could implement it, it is not that hard.
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Thanks for your reply anyway, --DeliQ
On Sat, Aug 25, 2007 at 01:58:09PM +0200, Ronny Prinse wrote:
Sure offcourse, I guess I saw it as a nice oppurtunity to get to know the pacman source code and do something back. Maybe if other people want this as well I could implement it, it is not that hard.
Sure, pacman definitively needs a lot of help in many places ;) See the recent 3.2 thread about all things that could be done. But, about that particular code handling pacnew / pacsave, I think it could be written more cleanly as well, but keeping the same behavior. Mostly by reorganizing / refactoring it and putting it in a new function.
participants (3)
-
Ronny Prinse
-
rprinse＠planet.nl
-
Xavier