Subject: Re: Developing packges with alternates as dependencies?
To: Jeremy C. Reed <reed@reedmedia.net>
From: Gary Thorpe <gathorpe79@yahoo.com>
List: pkgsrc-users
Date: 04/26/2007 23:28:20
--- "Jeremy C. Reed" <reed@reedmedia.net> wrote:

> On Wed, 25 Apr 2007, Gary Thorpe wrote:
> 
> > but if ../../sysutils/progwithlibs (which has standalone-libs as
> part
> > of its distribution) has already been installed, then I would want
> to
> > use the libraries bundled with it already.
> > 
> > Is this possible to do?
> 
> If I understand you correctly, this is can be handled via builtin.mk 
> files, for example:
> 
> pkgsrc/devel/libevent/builtin.mk
> 
> These can be tricky to write and to test. But there are many
> examples.
> 
> We can help more if you provide exact package in progress -- maybe
> commit 
> your work in progress to pkgsrc-wip?
> 
>   Jeremy C. Reed
> 

The example you point is close to but not exactly the situation, so let
make a more clear outline:

PKG_A <- requires a header file which is not in the base system (I
think the other case is what builtin.mk handles from a quick browse of
the file)

PKG_B <- set of utilities, supporting libraries and header files; has
header needed by PKG_A

PKG_C <- subset of PKG_B, created by developers of PKG_B (not me)
because other utilities need the supporting headers/libraries in PKG_B
but don't necessarily want the utilities and excluding them saves a lot
of space; conflicts with PKG_B; has header needed by PKG_A

All three packages exist in reality (is this really that uncommon?). To
build PKG_A, one of PKG_B or PKG_C must be present (doesn't matter
which, a preference doesn't matter and can exist). If someone wants
PKG_A and has PKG_C installed already, then they don't have to build
PKG_B (which would conflict with PKG_C anyway). Converse is also true
if you switch around PKG_B/PKG_C.

So, B and C support the same interfaces/headers used in A. How do you
specify this in PKG_A's Makefile in pkgsrc? This is the actual
situation with the package I am trying to get into pkgsrc.

I am planing to submit to pkgsrc-wip, but this seems like a good thing
to resolve first. The package builds fine now with just one dependency
(PKG_C, which was easier to import), but if I leave it as as, the
scenario outlined above may make it not so build-able (e.g. someone
installed PKG_B already). An earlier version of PKG_B (possibly
outdated) is already in pkgsrc, so this may not be unlikely. 

Using package options to specify dependencies seems awkward, especially
since the package has no native notion of this option (it just looks
for the header it wants with 'configure').

Thanks for any insights!


      Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca