- Pacman-dev - lists.archlinux.org

[pacman-dev] Is there plans to improve perl modules handling?
by Роман Кирилич 29 May '06

29 May '06

Hi! I noticed on Fruglaware's site that they have new system of installing perl modules from CPAN - fwcpan which is integrated with FwPacman to support dependencies. Is something like that planned for Arch in some distant future? And if yes - will this work with new pacman to support such module management with dependencies?

2 2

[pacman-dev] config handling
by Роман Кирилич 26 May '06

26 May '06

>> * lib/libalpm/add.c: changed behaviour with >> original=X,current=Y,new=Z backup scenario -- install new file as >> .pacnew and keep old one in place >> >> it seems that later it was backported to pacman2 >> >> just wanted to mention you that before this change the NoUpgrade option >> was really important >> > > Ha yes indeed, this change was made in the latest 2.9.8 release, and it's indeed > very important. But that's really the way it should have been since the start > (since there are no automerging kind of stuff, which doesn't really matter btw :)). > Now if these pacnew files are only extracted when the default config files were > actually updated, it'll be easier to track down these changes and update manually > the corresponding config files. > I'm glad that you agree that NoUpgrade is less important now, and I can also see > why it was needed before. > So either NoUpgrade should be removed, or moving config files outside NoUpgrade > should be fixed by storing the correct md5sum. My patch does it, since it makes > pacman handle config files in NoUpgrade like the others, but it also checks > md5sum to see whether the pacnew file needs to be extracted or not. So the only > difference left is in the case : > original=X,current=X,new=Y > where the config file should be safely updated, but NoUpgrade still prevents it > (but doesn't make much sense to me). Hi! I'm new to this list, so please sorry if I do some stupid things. :) Just want to say: NoUpgrade should not be removed! It is very important if, for example I have modified rc.sysinit and don't want it to be silently overwritten during upgrade. For config files (files that are in backup=() array) NoUpgrade is not needed, but it is useful for other files that were modified by user.

4 12

[pacman-dev] config handling
by x.chantry＠wanadoo.fr 26 May '06

26 May '06

First, I've to say that I don't see the point of NoUpgrade feature. Default pacman config handling is just great, it'll never overwrite a config file you edited, it'll only upgrade the config files you never edited. Why would anyone not want this ? It just looks like the only sane thing to do. Secondly, since it seems that NoUpgrade makes sense for most people (please tell if I'm not alone finding it pointless :)), there is a very annoying thing with it : it always extract the config file to pacnew, no matter if the current config is the same (you didn't edit it), or the original is the same (you edited it, and want to keep your config file, not reverting to the default config). Thus most of the times, you'll have a pointless pacnew files. It's harder to track when a config file got updated or not. Finally, since I dislike current NoUpgrade behavior, I wanted to remove the config files from there and get the (nice) default pacman config handling, which does just the right thing. But, when a config file is in NoUpgrade, and you (re)install the corresponding package, pacman stores the md5sum of /etc/foo (ie your current local config file), instead of /etc/foo.pacnew (pkg config file). So when you remove a config file from NoUpgrade, and reinstall the package, you are in the case : original=X, current=X, new=Y which is the only case where pacman actually overwrites the config file, which is perfectly right, except that here, the original md5sum is wrong (it's the current config file, instead of the previous pkg one). So you actually lost your custom config file, which pacman should never allow. (I hope you understand that NoUpgrade is the problem causing this, not an answer). I've made a patch that makes NoUpgrade behave less annoyingly (even if I would rather remove it totally), by only extracting a pacnew file when the pkg config file has changed (original = X, new = Y), so no more useless pacnew files. And it fix in the same time the above issue. It always made me feel better with last filesystem upgrade :) (where most of its config files are in NoUpgrade, but the last package update didn't modify these config files, so pacman didn't extract them as .pacnew)

2 5

[pacman-dev] Problem with pacman 3 and groups
by Wael Nasreddine 25 May '06

25 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There's a problem with pacman well at least the one from VMiklos darcs, I didn't test the one in arch's repository though but I'm pretty sure it has the same issue. If packages in 2 repositories are members of the same group, pacman sees 2 groups with the same name instead of one group containing packages from both repo, First i thought it ain't a bug but more or less future feature but when I tried to install a group, pacman tried to install packages from the first repository in pacman.conf, and not all packages. - ---------------- CUT (0)[root@nasreddine ~]# pacman -Sg gnome gnome gnome-icon-theme gnome control-center epiphany gnome-applets gnome-backgrounds gnome-common gnome-desktop gnome-media gnome-mime-data gnome-panel gnome-session gnome-themes gnome2-user-docs metacity nautilus vte yelp (0)[root@nasreddine ~]# pacman -S gnome :: group gnome: gnome-icon-theme :: Install whole content? [Y/n] - ---------------- CUT Regards, Wael Nasreddine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEdZjxVWU5RcjdGKIRAoZDAJ91A3jm2Y+6WspmVrnztiS8COhM4gCbBPXH tavQq9fIjDALiXHbYIfn2Dg= =b5QL -----END PGP SIGNATURE-----

1 0

[pacman-dev] [PATCH] pacman: workaround for tr_TR in i18ninit()
by VMiklos 19 May '06

19 May '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…; udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

1 0

[pacman-dev] Little problem with -Qm option (for foreign packages)
by x.chantry＠wanadoo.fr 16 May '06

16 May '06

As stated here : http://bbs.archlinux.org/viewtopic.php?t=21311 There is a little problem with the -Qm option. The string comparison is not strict enough. For example, if xarchive isn't in any repos, and xarchiver is in community, then pacman won't show xarchive as being a foreign package. I was thinking about comparing the length of the strings first, before strstr. What about the conversion to uppercase? is it really needed?

2 2

[pacman-dev] [PATCH] pacman: log_cb() check for strlen(msg), not strlen(str) which is always true
by VMiklos 15 May '06

15 May '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…; udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 1

[pacman-dev] [PATCH] use LOG_STR_LEN for error/warning/debug messages, too
by VMiklos 06 May '06

06 May '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…; the current buffer's length is only 9 chars which is ok for English but not for other languages udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

1 0

[pacman-dev] [PATCH] makepkg: handle spaces in source filenames
by VMiklos 28 Apr '06

28 Apr '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…; i know, it does not apply cleanly to the cvs, but Aurel already said previously it's not a problem, so then i won't fix it up udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

1 2

[pacman-dev] [PATCH] libalpm: yet another fix for conflits&provides
by VMiklos 10 Apr '06

10 Apr '06

hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…; the scenario is the following: pkg B provides and conflicts with pkg A pkg E depends on pkg C and pkg D pkg C depends on pkg A and pkg D depends on pkg B so during a -S E, pkg A should be removed from the target list no log message needed we already have: debug: package 'xespgs' provides its own conflict flow2: removing 'espgs' from target list which should be enough imho applies to the latest Arch cvs maybe it would be good to create a test for this scenario udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 3