Greetings All.

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
are installed.
2. pkg_admin searches /var/db/pkg with directories named
packagename-version
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?


Best regards,

Please CC answers, I am not subscribed (yet?)
-- 
Miłego dnia
>Łukasz<