You are not logged in.
Say I have two versions of nspr.
$ ls -1 nspr*.pkg.tar.xz
nspr-4.10-2-x86_64.pkg.tar.xz
nspr-4.9.6-1-x86_64.pkg.tar.xzWhen I run repo-add on both of them, version 4.9.6 will be the one remaining in the database.
$ repo-add custom.db.tar.gz nspr*.pkg.tar.xz
==> Extracting database to a temporary location...
==> Adding package 'nspr-4.10-2-x86_64.pkg.tar.xz'
-> Computing checksums...
-> Removing existing entry 'nspr-4.9.6-1'...
-> Creating 'desc' db entry...
-> Creating 'depends' db entry...
==> Adding package 'nspr-4.9.6-1-x86_64.pkg.tar.xz'
-> Computing checksums...
-> Removing existing entry 'nspr-4.10-2'...
-> Creating 'desc' db entry...
-> Creating 'depends' db entry...
==> Creating updated database file 'custom.db.tar.gz'I think here the natural order should be used, something like
$ repo-add custom.db.tar.gz $(ls -v nspr*.pkg.tar.xz)as this is the expected behaviour from most users.
Last edited by luran (2013-10-07 23:43:21)
Offline
When only one version of a package will ever be present in the db, why try adding more? Just pass the version you want. You can use 'ls -v' if you prefer, but I think it's the shell's interpretation of the wildcard and not repo-add to blame.
Offline
repo-add --new
Offline
repo-add --new
Either I'm completely misunderstanding OP or you are. Even with '--new' only the last (as in the last argument in that command) version of the package will remain in the db. It doesn't mean the latest one, the problem is still the same.
Last edited by karol (2013-08-11 01:13:24)
Offline
When only one version of a package will ever be present in the db, why try adding more? Just pass the version you want. You can use 'ls -v' if you prefer, but I think it's the shell's interpretation of the wildcard and not repo-add to blame.
Thanks for your reply. Now I agree repo-add should just process the files according to the order given by the shell.
To anwser your question, I need to make a local repository regularly to be shared with my other machine, because I have a very limited Internet quota and the sharing roughly halves the downloads. Usally I just use the wildcard for all the packages in the cache, and it works fine as long as the package version does not jump to 10+ like the above example. 'ls -v' will do the job for me. Cleaning the old packages could be another option, but occasionally I need to revert some package back to an old version.
Offline
There are many ways to share the package cache https://wiki.archlinux.org/index.php/Cu … cman_cache
Offline
I quite expectedly recommend pacserve for sharing packages across computers. The shared cache method can easily remove packages that you'd like to keep when cleaning the cache, unless both systems use exactly the same set of packages.
Incidentally, repo-add_and_sign will filter the command-line arguments so that only the latest version of each package is added to the repo.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline