- Pacman-dev - lists.archlinux.org

[pacman-dev] add message() function call for use in *.install/.PKGINFO files
by Роман Кирилич 07 Jul '06

07 Jul '06

Different packages use different style to output some info for user. They use echo, but prefixes information with different chars (" >>> ", " ==> ", " >> " etc.). I think it will be better if there will be message() function that can be used for such purpose. This will not only make all such info messages the same style, but also this will allow to cache such messages and display them after upgrade process (this is very useful when upgrading many packages). What do you think?

4 17

[pacman-dev] [PATCH] display uncompressed package size before downloading
by VMiklos 08 Jun '06

08 Jun '06

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

1 0

[pacman-dev] little bug with pacman and root
by wael＠siemens-mobiles.org 05 Jun '06

05 Jun '06

Hi, Let's consider the following setup: I have a distribution (any distribution it doesn't matter) installed on / where am looking to install arch or frugalware on a chroot from it, So pacman has been extracted to / and pacman.static is used... let's suppose /arch is the chroot... As i always install and upgrade I keep the pacman cache in /home partition under /home/cache/pacman and create a symlink ( /var/cache/pacman -> /home/cache/pacman ), so for instance /arch/var/cache/pacman is a symlink to /home/cache/pacman (I know the link is broken but that's the idea), Now I run pacman.static -Sy -r /arch bash db binutils kernel26 Of course pacman will begin by saying, /arch/var/cache/pacman does not exist... creating it (since the symlink is broken) but it also fails to create it, so pacman decides to use /tmp and here it is all messed up, it start downloading packages to /arch/tmp and it fails on checking packages integrity it seems it is trying to do that on /tmp instead of /arch/tmp.. Regards, Wael Nasreddine

3 4

[pacman-dev] Pacman color output
by Wael Nasreddine 04 Jun '06

04 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I don't know if you have discussed this before, any chance to see color support to pacman's output? i really loved the way pacman does the download when adding "ilovecandy" to /etc/pacman.conf :D, so I tried to add some colors but since the string length is checked in pm_fprintf function, it may break the message, I tried doing it in another way (by simply adding an extra char *color to pm_fprintf function) but I am not a C++ programer so i failed specially about adding strings together (color + str + CLEAR) to fprintf, anyone interresting in doing it ? Regards, Wael Nasreddine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEgsaFVWU5RcjdGKIRApalAJ0btdXfcN25YSWz7y8YCXYnJpVYvgCgvWF4 sK/TTvg3yz8T2y6TboCqDv0= =DoAW -----END PGP SIGNATURE-----

2 3

[pacman-dev] internationalized package descriptions?
by Maksim Sipos 04 Jun '06

04 Jun '06

Hello, I've been interested in i18n support for the upcoming pacman. I've noticed patches on the subject of gettext support and all that and I think that is wonderful! Now I'm thinking how it would be feasible to implement localized package descriptions. I am imagining something like pkgdesc_xx fields (xx being the language codes) in PKGBUILD scripts, and smart pacman frontends that would show the translated description string based on the users locale, if it is available (otherwise, show the english pkgdesc). Now, before I start hacking at the code, I would like to see what others think of the idea, and potential ways of designing it. I'm also interested in knowing how well adding fields like this would play out in pacman's database. I think it would be really cool if pacman had this feature :). Cheers, Maksim

3 3

[pacman-dev] [PATCH] gettext support - part 1
by VMiklos 02 Jun '06

02 Jun '06

hi http://frugalware.org/~vmiklos/patches/libpacman-proposed/gettext.diff.bz2 here is the first part of the gettext support patch it only adds the necessary gettext function calls. the advantage of this patch: - it contains most of the modifications so once you apply it, probably the other patches will apply without any conflits, the conflicting parts are contained in this patch - it's simple, almost doesn't do anything else so it can be reviewed easily the next patch will modify the build system, but that should be really a separate patch imho as usual, probably it does not apply cleanly, Aurel could you fix it up? (as you said it's not a problem if it does not apply) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

2 14

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

29 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) iD8DBQFEdNttVWU5RcjdGKIRAm7dAJ95RkYhqa3PzJcosfINGwobqkwatQCg6LBf 0aEyWZ5CRqSOFTOtlJMJy/o= =KcC3 -----END PGP SIGNATURE-----

2 7

[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 Роман Кирилич 27 May '06

27 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