Re: Method to override buildlink inclusion

[Martijn van Buul <pino%dohd.org@localhost>]

* Greg Troxel:
> Martijn van Buul <pino%dohd.org@localhost> writes:
>
>> For a few software packages, there are several versions in pkgsrc -
>> especially if you include wip into consideration. For example, there's
>> lang/clisp, wip/clisp and wip/clisp-current, and they're all
>> different. Likewise for lang/mono and wip/mono. Is there a clean way
>> to inform pkgsrc that I do *not* want lang/mono (since it won't even
>> compile), but that it should use wip/mono instead?
>
> Are you talking about the package being a dependency?

Yes.

>> I'm even prepared to do this on a per-package basis. Right now, I have to
>> modify the package makefile and change the included buildlink, and I can't
>> help but wonder if there isn't a more elegant solution. 
>
> which package makefile do you have to modify?

Two examples:

wip/pkgmanager, includes lang/clisp's buildlink.mk. However, lang/clisp 
doesn't build for amd64, wip/clisp does - and should be a drop-in replacement.

However, the only way I can make things work right now is manually change
the path of the included buildlink.mk. 

Same applies for x11/gtk2-sharp, which depends on lang/mono (doesn't work
for amd64), while wip/mono does.

I'm sure there's other examples to be found, and I don't think it's a
coincidence that wip is involved. In fact, I think this is about to happen
moreoften due to the "low entry level" of wip (which was one of the main
objectives of that project, if memory serves me right). People spot an 
outdated package in 'proper' pkgsrc which is either maintained by
pkgsrc-users@, or whose maintainer seems to be sleeping at the job, and
address this by creating a sister package in wip. This is just fine if it's
a "leaf" package (that nothing else depends on), but if it's a dependency
to other packages this makes it a hassle to replace the pkgsrc version
with the wip version in one fell swoop.

I understand that pkgsrc doesn't really want to know anything about wip, and
that it's not desireable to use the same mechanism used to select alternative
versions as used by pkgsrc itself.

> Two proper solutions come to mind:
>
>   a) commit the wip versions into real pkgsrc

If they're done and ready, sure. However, they might not be ready for prime
time yet. I'm quite happy to run a version of clisp or mono that might not
be ready for prime time (as the official packages don't work for me), but 
someone on i386 might think different about this, and rightfully so.

>   b) add a mk/foo.mk file that enables switching, like we do for various
>   providers of the same code in pkgsrc
>
> In these cases b seems a bit silly.

My main peave with b is that I don't think it's a good idea that lang/mono
should know there just *might* be an alternative lurking around in wip/mono,
unless this can be solved in a generic way, so that misc/xyzzy can be
substituted with wip/crossproduct seamlessly..

> Have you written to the maintainers?  I don't use either of these, and
> thus can't judge if they're ok. 

Neither can I, and I didn't even want to imply that they might. I didn't
really want to create any big fuss; I was told on IRC that wip/mono would
probably work on amd64, so I wanted to give it a spin - at which point I 
wondered wither

find /usr/pkgsrc . -name 'Makefile' | xargs grep "lang/mono" 

(and manually hacking the returned Makefiles) really was the only way to
switch to using that version instead of the pkgsrc one. If the answer to that
is "yes", that's ok with me; I was just hoping I overlooked something.

> The wip/mono package is not even a week old, and wip/clisp seems to have been
> created on 2008-01-29, which puts it at 2 weeks.

wip/clisp is actually older than that, IIRC; it's been in wip under a different
name for a while already, but that's not really important.

-- 
Martijn van Buul - pino%dohd.org@localhost