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