- Pacman-dev - lists.archlinux.org

[pacman-dev] [translation] Russian translation updated
by serg 07 Oct '08

07 Oct '08

I've corrected some errors.

2 2

[pacman-dev] [PATCH] Print a newline between packages when printing sync info.
by Loui 03 Oct '08

03 Oct '08

Reading sync info of more than one package was a bit confusing so I added a newline so it's easier to read.

2 2

[pacman-dev] [PATCH] Mention libarchive and libdownload as dependencies in INSTALL.
by Loui 02 Oct '08

02 Oct '08

This is just to give people trying to build pacman more info right off the bat.

2 2

[pacman-dev] Multiple/Shared Architectures
by Teran McKinney 29 Sep '08

29 Sep '08

Hey, I've planned out a set of changes I want to try with Pacman and Makepkg. Most deal with creating a source repository setup that would store source files as their sha512sums, but that isn't related to this. Another thing that I want to do is have a "shared" repository for non-architecture specific packages. I would rather not use different repositories for the "shared" architecture, ie: core-shared, extra-shared. Here is my current mirror layout: icadyptes/i486/{core,extra} The shared architecture could be at: icadyptes/shared/{core,extra} I'm sure that this conflitcts with a few things inside libalpm, but here is my proposed implmentation: pacman.conf: SupportedArchs = i486 shared (Could have i686 too, or anything making this useful for other tasks) mirrorlist: Server = ftp://icadyptes.go-beyond.org/icadyptes/$arch/$repo A shared repository would save disk space on mirrors, as well as bandwidth (to a lesser extent). The makepkg implementation for this could simply be setting $arch to shared. Distributions using Pacman would need to change other things for this to work properly, but in my opinion, it is a clean change that could be very useful. Packages could be queried for just like they are if it is not immediately found in the first repository, checking until it finds an architecture with the package's name. This could serve other purposes, too. With additional hacking (and possibly pacman.conf options), doc files could be split into seperate packages (and hence a different repo), and be given the "doc" architecture. Users would add "doc" to SupportedArchs (I'm sure this could have a better name), and when they download a new package the doc files would come in a seperate package with it. SupportedArchs would also be ordered by preference, so perhaps it could be pentium4, i686, i486, shared, so that packages (on an incomplete build) more optimised for a certain architectures would be prefered over their lesser-optimum counter parts (sure that this induces a few potential problems though). Now that I think about it, there could even be a $distribution setting for people wanting to pull packages from multiple distributions :-P. You guys have already put a ton of work into Pacman, and made it one awesome package manager. Not sure if this idea interests you or not, but it is something I'd really love to have in my Arch fork. I'm willing to code this in myself, but I'd need to learn more C first, and am sure that any of you could do it in much less time. Let me know what you think of it, and if you have any suggestions or ideas. Thanks, Teran (sega01) PS: I think that the stock makepkg should default to arch=(any) if $arch is not set. I do this in Icadyptes, and it is a very safe (to my knowledge) and easy hack. Has there been any discussion or patches regarding PGP signed database files?

3 3

[pacman-dev] Add rsync vcs support to makepkg
by Mark Constable 29 Sep '08

29 Sep '08

Plus a couple of other minor points. Qt daily snapshots are only available via rsync (and tarballs) so I added _rsyncroot and _rsyncmod awareness to makepkg. elif [ ! -z ${_rsyncroot} ] && [ ! -z ${_rsyncmod} ] ; then [ $(type -p rsync) ] || return 0 msg "$(gettext "Determining latest rsync revision...")" newpkgver=$(date -u +%Y%m%d%H) The date format is per hour so multiple updates per day are possible and the -u is UTC so the the timestamp is universal worldwide. Whilst submitting a patch I thought I'd throw in this option for consideration which is to use the pkgrel variable as the VCS version field rather than pkgver. if [ "$USE_PKGREL" != "" ]; then msg2 "$(gettext "Package release version found: %s")" "$newpkgver" pkgrel=$newpkgver else msg2 "$(gettext "Version found: %s")" "$newpkgver" pkgver=$newpkgver fi It requires a new USE_PKGREL argument (see attached diff). It makes it easier to offer packages called qt-snaphot-4.4.1-2008092301 and qt-snaphot-4.5.0-2008092301 And finally, this minor tweak ensures that a pkgver=$(date) or pkgver=$EXPORTED_GLOBAL_VAR will not be overwritten... - sed -i "s/^pkgver=[^ ]*/pkgver=$newpkgver/" ./$BUILDSCRIPT + sed -i "s/^pkgver=[^$ |\$$]*/pkgver=$newpkgver/" ./$BUILDSCRIPT --markc

2 1

[pacman-dev] Show total progress bar
by Nathan Jones 28 Sep '08

28 Sep '08

Hey folks, Message about the TotalDownload option from way back in November 07: http://archlinux.org/pipermail/pacman-dev/2007-November/009948.html Back then, I did not know how to draw two progress bars. Well, now I have figured it out (and it only took ten months, not bad). I have a really terrible patch right now which somewhat works. If everyone thinks that having two progress bars is a good thing, then I will make a better patch. I don't know if it is a good thing or not. The output is a bit overwhelming, but it is fun to look at. To see what having two bars would look like without having to apply the patch, try this python script: import sys import time print 'pacman [###-------] 25%' print 'total [##--------] 10%', sys.stdout.flush() time.sleep(1) sys.stdout.write('\033[A\033[K\n\033[K\r\033[A') print 'pacman [#########-] 90%' print 'total [#####-----] 50%', sys.stdout.flush() time.sleep(1) sys.stdout.write('\033[A\033[K\n\033[K\r\033[A') print 'pacman [##########] 100%' print 'gcc [##--------] 10%' print 'total [######----] 60%', sys.stdout.flush() time.sleep(1) sys.stdout.write('\033[A\033[K\n\033[K\r\033[A') print 'gcc [######----] 60%' print 'total [########--] 80%', sys.stdout.flush() time.sleep(1) sys.stdout.write('\033[A\033[K\n\033[K\r\033[A') print 'gcc [########--] 80%' print 'total [#########-] 90%', sys.stdout.flush() time.sleep(1) sys.stdout.write('\033[A\033[K\n\033[K\r\033[A') print 'gcc [##########] 100%' print 'total [##########] 100%'

2 2

[pacman-dev] possible bug?
by Roman Kyrylych 28 Sep '08

28 Sep '08

Hi! Stumbled upon this today: http://bugs.archlinux.org/task/11498 Can this be somehow related to the fact that Pacman doesn't store ownership of directories? -- Roman Kyrylych (Роман Кирилич)

1 0

[pacman-dev] [PATCH] makepkg: Add used options to PKGINFO file
by Allan McRae 27 Sep '08

27 Sep '08

Adds defined options to the PKGINFO file in the form of "makepkgopt =". It may be useful to be able to add these to the pacman DB at some point as that would allow (e.g.) checking which packages have had their docs striped (FS#7092). Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c15d91f..f5a5af4 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -41,8 +41,9 @@ confdir='@sysconfdir@' startdir="$PWD" srcdir="$startdir/src" pkgdir="$startdir/pkg" -known_options=('strip' 'docs' 'libtool' 'emptydirs' 'zipman' 'ccache' 'distcc' 'makeflags' 'force') -readonly -a known_options +packaging_options=('strip' 'docs' 'libtool' 'emptydirs' 'zipman') +other_options=('ccache' 'distcc' 'makeflags' 'force') +readonly -a packaging_options other_options # Options ASROOT=0 @@ -844,6 +845,16 @@ create_package() { for it in "${backup[@]}"; do echo "backup = $it" >>.PKGINFO done + for it in "${packaging_options[@]}"; do + local ret="$(check_option $it)" + if [ "$ret" != "?" ]; then + if [ "$ret" = "y" ]; then + echo "makepkgopt = $it" >>.PKGINFO + else + echo "makepkgopt = !$it" >>.PKGINFO + fi + fi + done # TODO maybe remove this at some point # warn if license array is not present or empty @@ -1385,7 +1396,7 @@ valid_options=1 for opt in ${options[@]}; do known=0 # check if option matches a known option or its inverse - for kopt in ${known_options[@]}; do + for kopt in ${packaging_options[@]} ${other_options[@]}; do if [ "${opt}" = "${kopt}" -o "${opt}" = "!${kopt}" ]; then known=1 fi -- 1.6.0.2

1 1

Re: [pacman-dev] handling info files
by Miklos Vajna 21 Sep '08

21 Sep '08

On Sun, Sep 21, 2008 at 08:43:17PM +1000, Allan McRae <allan(a)archlinux.org> wrote: > Yes, but the compressing of info pages is only on the master branch. There > is no automatic removing of the dir file but that would require hard-coding > a file name into makepkg which I am not too sure about... I don't exaclty know how you can do it with your KISS way, but we have a (you can call it distro-specific) install macro that already does stuff like removing perl's perllocal.pod/.packlist files, etc. That macro takes care of removing such info dirs as well.

1 0

[pacman-dev] handling info files
by Andreas Radke 21 Sep '08

21 Sep '08

Now that we decided that we want to ship info documentation we should decide how to package such files: info files could be gzipped by makepkg or stay uncompressed. On my system they already take quiet a lot of space compared to much more packages shipping man-pages: [root@workstation64 andyrtr]# du -ch /usr/share/info/ 21M /usr/share/info/ [root@workstation64 andyrtr]# du -sch /usr/share/man 61M /usr/share/man Some are really big like gcc.info being 1.8mb uncompressed. I vote for auto-gzipping the info pages like man-pages. And shouldn't we check and remove the $pkgdir/usr/share/info/dir file that every pkg with info files produces? Maybe we can also print at the end of the makepkg run an array of found info files the packager should put into the *.install file. Right now we use the proto-info.install shipped with the "abs" pkg. An automated solution would be also nice for that. Opinions? -Andy

4 3