(off we go to tech-pkg)

On Sat, Feb 18, 2006 at 12:26:47PM +0100, Julio M. Merino Vidal wrote:
> On 18/02/2006, at 11:59, Adam wrote:
> >(...)It's easier to maintain this way.
> 
> I haven't looked at that package myself... but, really?  If you have
> multiple options, you should build the package with each of them during
> an update to verify they still work.  Doing this with different packages
> is easy, not so much with options.  Also, bulk builds will not catch
> build problems with the different GUIs...

This means the bulk and test builds need to be made option aware. If
you introduce ipv6 and no one runs it is that a reason to dump ipv6
again - it only causes trouble for those who do not run it and touch
anything which might affect it some way.

> >Why not making binary packages for different options? :)
> 
> Yes, why not?  I'm not a big fan of build time options. For me
> less, the better: a binary-only user should be able to have a wide
> variety of applications and not be forced to rebuild them himself. (...)

You haven't answered the question. Yes there shouldn't be only binary
packages for one "flavor" around (as you yourself also mandate). But
one place to groom and maintain seems enough.

> I would like us to enforce a policy so that pkgsrc was binary-package
> friendly; and this means lessening the number of available options.

How does that mean lessening the available options ? It should
mean building binary packages with the possible option permutations
and not build a list of entries in pkgsrc which differ only in
one more (or less) argument to the pkgs 'configure' script IMHO.

There is no causality between "build different flavors" and "dump options".
The only appeal I see to having different pkgs with all but one setting
the same is increase the count of pkgs we have in pkgsrc. Imo pkgsrc doesn't
need that kind of "advocacy".

> In my opinion, it's a good selling point over, e.g., the ports and
> portage.  In fact... this is one of the reasons I liked pkgsrc when I
> saw it: the ports were a real mess with all those options.
> Unfortunately, it seems we are getting there...

If that's the case (WHY ??) do it the netbsd way - *Get It Right* instead
of dumping it for something which multiplies the entries just in favor
for one or two different switches to configure.

Regards,

-Martin