list of package names, versions[, descriptions]

[Eli Schwartz]

On 9/30/19 9:44 PM, Greg Minshall wrote:
> hi.  i'd like to keep a copy of the list of AUR packages, version
> numbers, and descriptions on my machine.  the list can be somewhat out
> of date (say, as of the last time i did "pacman -Syu", which, for me, is
> every week or two).
> 
> my question is how to do it with minimal overhead?  i know packages.gz.
> that will give me the list of packages.  however, without the version
> numbers, i won't be able to tell whether my cached information for a
> given package is up to date or not.

packages.gz only gives you names, the list of names is up to date if the
snapshot date says it is up to date and version numbers don't enter into
it. If you have additional cached information for a given package, then
that presumably includes the version. So I'm not sure I understand the
comparison to packages.gz

At any rate...

> would it be possible to (put on the list to) provide at some point a
> "packages-versions.gz"?  or, even, "packages-versions-descriptions.gz"?
> (though the former is probably of more general use.)

Neither one is very useful for general use, "general use" would mean
providing the information people want for arbitrary offline queries, so
what you're actually asking for is a regular database dump of all
packages and their multiinfo descriptions.

It may be that for your specific use, you only need name, version and
description... other people have had similar offline requests where they
wanted everything from dependency information to the name of the
maintainer (off the top of my head, https://repology.org is currently
importing the name, version, maintainer, url, description, and license
-- all via repeated RPC calls for the multiinfo data).

> below is my motivation for wanting this.  apologies if i've missed some
> already existing way of doing this.
> 
> cheers, Greg
> ----------------------------------------------------------------------
> motivation:
> 
> for the last several years i've been using a script i "wrote" (inspired
> by something similar from fink) that, from local information, lists
> available packages, install status, version numbers, and descriptions
> [1].  (i'm often in a disconnected, or badly connected, world, so i try
> to avoid relying on the web.)

But in order to actually use the information from the AUR, you would
need to be online, because you need to be online in order to retrieve
the PKGBUILD and build the desired package.

> having converted recently to arch, i pulled my script up to pacman [2],
> and would like to do an aur version, as well.

For local packages I would just use expac, a printf-style formatter for
libalpm database information, which will be both faster and more
accurate than running pacman -Si/-Qi in a tight loop in a python script
followed by using regular expressions on the output.

> for "packages-versions.gz", i'd download that, then use the package
> names and versions to make queries to bring a local database up to date
> with what AUR has.  i'd damp this process to once a week or so.
> 
> (i've spent some time in the last week, offline, playing with figuring
> out how efficiently -- in terms of both number of requests and amount of
> [duplicated] data transmitted -- i can download all the information via
> repeated RPC searches on frequently-appearing search terms -- using
> packages.gz as a way of knowing all the entries.  but, as fun as that
> is, it's a hack.)

For AUR packages, I'm still not entirely sure why you need all this
information for the 99% of packages that you won't ever use, and for the
ones you do use you likely want the PKGBUILD too.

In a general sort of way, what you want reminds me of the old AUR-mirror
project, which was a giant git repo of every PKGBUILD in the AUR (this
was before the migration to git, so everything was tarballs, and this
was meant to pull them all together and provide history for the daily
snapshots). Today, I guess you could clone 55603 package bases from git,
thus ensuring you had fully up to date offline information for anything
you cared to do. That would sort of slam our server, though.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20191002/c62f11bf/attachment-0001.sig>