[arch-general] new arch user, questions about package management
Hi, For various personal reasons including the rolling release model (which is critical to me), easy package building and availability of binary packages and build scripts I'm considering changing to arch. I do have a few questions that I can't seem to find the answers to, sorry if they are covered in the forums, I did look there but couldn't find the info I'm looking for. eix like tool: Is there a utility similar to gentoos 'eix'? From the eix man page: eix - a set of utilities for searching, diffing and updating a binary cache of your local portage-trees What I'm looking for is a way to see a diff of my package cache prior to and just after syncing, i.e. what packages are out of date (which pacman does show), what packages have been removed from the repositories since my last sync and what packages have been added to the repository since my last sync. eix does this nicely imho using optional color output, pacman-color (and pacman) does some of what I'm looking for but I'm not sure it will do the diff part. PKGBUILD I've built my own packages for tmpwatch, the oracle instant client and built tora with oracle support. I've found PKGBUILDs for backuppc and a few other packages that I need via AUR->Packages link off the arch home page. To me Arch package building is refreshing when compared to my experiences with ebuilds and rpm spec files. I can't seem to find a list of all the varibles that can be used in a PKGBUILD script though (like $startdir etc), where would I find that info? If I end up totally switching I want to make my own repository (like a yum or apt repository) of my custom packages for the systems I manage. I think I've seen a few pages on how to set that up but if there is an authoritative page someone knows of I'd appreciate it. I've been running arch on my laptop and home system for almost a week now and I am very happy with the results so far. Thanks in advance for your help, Dave
On Wed, June 11, 2008 14:45, Dave Heistand wrote:
Hi, Greetings!
What I'm looking for is a way to see a diff of my package cache prior to and just after syncing, i.e. what packages are out of date (which pacman does show), what packages have been removed from the repositories since my last sync and what packages have been added to the repository since my last sync.
To my knowledge, no developer supported package doing this is available, but there may be very well a host of shell scripts in one of the TURs fulfilling your requirements, more or less (likely less ;]). Some CVS magic on the ABS-tree may be the way to go, though, it's all in there. You just need to keep/extract the date of your last sync operation.
To me Arch package building is refreshing when compared to my experiences with ebuilds and rpm spec files. I can't seem to find a list of all the varibles that can be used in a PKGBUILD script though (like $startdir etc), where would I find that info?
Your best bet is 'man PKGBUILD'. You may, of course, define your own variables to use throughout the build process if you need any. Prefixing those with something (common choice is an underscore) to prevent name clashes helps, though. The Wiki elaborates on this in the packaging guidelines a bit.
If I end up totally switching I want to make my own repository (like a yum or apt repository) of my custom packages for the systems I manage. I think I've seen a few pages on how to set that up but if there is an authoritative page someone knows of I'd appreciate it.
http://wiki.archlinux.org/index.php/Custom_local_repository I've looked over it right now, and this is the way to go, using repo-add and repo-remove. To paraphrase the wiki page, just throw all packages you want to keep in your repository into an invariant directory, possibly using the PKGDEST variable in your build machine's /etc/makepkg.conf (see manpage for details), and run repo-add to define the name of the <foo>.db.tar.gz file in that directory, as well as all packages that shall be indexed (wildcards help). <foo> is then, by definition, the name by which your repository will have to be referenced in /etc/pacman.conf files. Sharing this directory via http/ftp is straightforward. Syncing will then consider your repo, and you may install explicitly versions from your repo by using the lesser known 'pacman -Sy <foo>/mypackage' syntax, where an explicit repo name is prefixed.
I've been running arch on my laptop and home system for almost a week now and I am very happy with the results so far.
That's always nice to hear! I always considered Arch's packaging one of the distribution's strong points.
Thanks in advance for your help, Dave
You're welcome, Dennis
On Wed, Jun 11, 2008 at 03:40:11PM +0200, Dennis Herbrich wrote:
What I'm looking for is a way to see a diff of my package cache prior to and just after syncing, i.e. what packages are out of date (which pacman does show), what packages have been removed from the repositories since my last sync and what packages have been added to the repository since my last sync.
To my knowledge, no developer supported package doing this is available, but there may be very well a host of shell scripts in one of the TURs fulfilling your requirements, more or less (likely less ;]). Some CVS magic on the ABS-tree may be the way to go, though, it's all in there. You just need to keep/extract the date of your last sync operation.
Thanks for the fast reply! I may have not been clear in my description. A diff of a snapshot of my local package tree/database (what pacman -Ss uses) prior to syncing and then a diff my local package tree/database after. Such a diff would tell me things like (output Packages removed from package tree/ftp servers: firefox (installed) foobar (not installed) Packages added to tree/ftp servers iceweasel (not installed) tmpwatch (not installed) Packages that need to be upgraded xorg (installed version 1, available version 1.2) cowsay (similar to above)) sysstat (similar to above) No big deal if there is no tool, I'll just need to check out the packages web page more often.
http://wiki.archlinux.org/index.php/Custom_local_repository
I've looked over it right now, and this is the way to go, using repo-add and repo-remove.
Perfect! Thanks again!
On Wed, Jun 11, 2008 at 5:25 PM, Dave Heistand <dheistand@challiance.org> wrote:
Such a diff would tell me things like (output
Packages removed from package tree/ftp servers: firefox (installed) foobar (not installed)
Packages added to tree/ftp servers iceweasel (not installed) tmpwatch (not installed)
Packages that need to be upgraded xorg (installed version 1, available version 1.2) cowsay (similar to above)) sysstat (similar to above)
No big deal if there is no tool, I'll just need to check out the packages web page more often.
there is the rss feeds too : http://archlinux.org/feeds/packages/
On Wed, Jun 11, 2008 at 8:55 PM, Dave Heistand <dheistand@challiance.org> wrote:
Such a diff would tell me things like (output
Packages removed from package tree/ftp servers: firefox (installed) foobar (not installed)
Packages added to tree/ftp servers iceweasel (not installed) tmpwatch (not installed)
Pacman stores all the repository data in /var/lib/pacman/sync/{repository} Also pacman has a feature of listing all the packages in a particular repository: pacman -Slq {repository} The -q is for suppressing the version information. So, to check the differences in say the core repository you could do: $ pacman -Slq core > core-old.txt # pacman -Sy $ pacman -Slq core > core-new.txt $ diff core-new.txt core-old.txt
$ pacman -Slq core > core-old.txt # pacman -Sy $ pacman -Slq core > core-new.txt $ diff core-new.txt core-old.txt
Sweet! Between that and the rss feeds I'm good to go! Thanks all!
On Wed, Jun 11, 2008 at 2:45 PM, Dave Heistand <dheistand@challiance.org> wrote:
To me Arch package building is refreshing when compared to my experiences with ebuilds and rpm spec files. I can't seem to find a list of all the varibles that can be used in a PKGBUILD script though (like $startdir etc), where would I find that info?
This is missing in the PKGBUILD man page : http://bugs.archlinux.org/task/10634
On Wed, Jun 11, 2008 at 04:16:07PM +0200, Xavier wrote:
On Wed, Jun 11, 2008 at 2:45 PM, Dave Heistand <dheistand@challiance.org> wrote:
To me Arch package building is refreshing when compared to my experiences with ebuilds and rpm spec files. I can't seem to find a list of all the varibles that can be used in a PKGBUILD script though (like $startdir etc), where would I find that info?
This is missing in the PKGBUILD man page : http://bugs.archlinux.org/task/10634
Great, that's what I was looking for. So, there is nothing like $mandir, $sysconfdir etc as there is in spec files? Just want to be sure. Thanks for the prompt response.
On Wed, Jun 11, 2008 at 9:52 AM, Dave Heistand <dheistand@challiance.org> wrote:
On Wed, Jun 11, 2008 at 04:16:07PM +0200, Xavier wrote:
On Wed, Jun 11, 2008 at 2:45 PM, Dave Heistand <dheistand@challiance.org> wrote:
To me Arch package building is refreshing when compared to my experiences with ebuilds and rpm spec files. I can't seem to find a list of all the varibles that can be used in a PKGBUILD script though (like $startdir etc), where would I find that info?
This is missing in the PKGBUILD man page : http://bugs.archlinux.org/task/10634
Great, that's what I was looking for. So, there is nothing like $mandir, $sysconfdir etc as there is in spec files? Just want to be sure.
Arch in 99% of cases uses mandir=/usr/share/man, sysconfdir=/etc, and never installs things under /usr/local. We don't want to enforce things like that at the makepkg level however, you are free to build local package however you like. -Dan
On Wed, Jun 11, 2008 at 5:04 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Arch in 99% of cases uses mandir=/usr/share/man, sysconfdir=/etc, and never installs things under /usr/local. We don't want to enforce things like that at the makepkg level however, you are free to build local package however you like.
This reminds me the $prefix proposal we had on pacman-dev... http://www.archlinux.org/pipermail/pacman-dev/2008-June/012052.html I don't know what to think about this idea of having more variables anymore. Just having these variables available don't enforce their usage. But if they were widely used, the whole thing would probably be more flexible. For example, I suppose the /usr/man -> /usr/share/man transition would have gone smoother.
participants (5)
-
Abhishek Dasgupta
-
Dan McGee
-
Dave Heistand
-
Dennis Herbrich
-
Xavier