Subject: pkgsrc on slackware, dependencies
To: None <firstname.lastname@example.org>
From: Lukasz Stelmach <email@example.com>
Date: 10/08/2007 00:10:33
I have installed pkgsrc on my slackware box. I am really happy that
I can do this because from my *BSD experience ports are the best
thing ever invented ;) and Slacware is my favourite OS/distribution.
I am really glad I can make those two great things work toghether.
OK enough of this sweetnes ;)
I would like to use pkgsrc as a secondary source of software. If there
is a native slackware package then I will install it and only if
there isn't one I will use pkgsrc. This means I have to teach pkgsrc
about slackware's installed packages. What I already know is:
1. pkg_admin is responsible for finding out if needed packages
2. pkg_admin searches /var/db/pkg with directories named
3. pkg_admin does some not too obvious magick matching versions
(BTW is there any comprehensive document about these patterns?)
One could use invoke here pkg_admin lsbest with -d /var/log/packages
but unfortunately slackware packages' names contain also architecture
and build number which makes perl package beeing named perl-5.8.8-i486-4.
In fact it isn't that hard to make a simple work just let the functions
in pkg_install lib/iterate.c know that they have to strip two additional
fields. To make it more general a set of function could be created
to replace iterate_local_pkg_dir and/or pkg_dir_iter to support
different package databases.
On the other hand it seems quite reasonable not to touch pkg_install
tools at all bu create quite new ones (e.g slack_lsbest).
The third option is to create some redundancy by reflecting
/var/log/packages in /var/db/pkg.
Please tell which of this options seems best?
What about different operations that need to be performed on
the package database and should/could be emulated on the
nateive package database?
Please CC answers, I am not subscribed (yet?)