On 18/02/2006, at 15:47, Martin S. Weber wrote:

> (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:
>
>>> 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

Oh, well.  Take the typical option-aware package with, say, only 3
options.  All the possible permutations could mean what, 8 binary
packages?  pkg, pkg-a, pkg-b, pkg-c, pkg-a-b, pkg-a-c, pkg-b-c,
pkg-a-b-c.  This is ridiculous and unaffordable: too much disk space
required to build them all and too much build time.  Bulk builds
already take a lot of time to run.

Also, something that I forgot to mention: options are harmful for
dependencies.  Say you have two packages, A and B, so that B depends
on A.  But B requires an A package built with, e.g., GTK support.
If A is built without GTK support, B's build will fail.  This situation
is difficult to express (in fact, impossible in the current pkgsrc
unless you have different binary packages with different names) and
could, as I see it, lead to more maintenance problems than we have
now.

> 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".

A maintainer is responsible for a package.  He has to choose a  
reasonable
set of options to build it and that defines what the package is.  He
needn't provide all and every way to build a single package.  If I say
"I installed the foo package", I want to know what that means.   
Having dozens of options does not help and leads to lots of trouble  
(specially
if you need to track a bug).

Also, options are harmful because maintainers add options without
thinking if there is another, more binary-friendly way.  As a personal
experience, take the gst-plugins package.  When I first got it, it had
a huge set of dependencies (I don't remember if they were tunable or
not).  I split that package in several different ones, which makes it
binary friendly.  Binary-only users now have the ability to choose.
Instead, the gst-plugins package in FreeBSD's ports has a huge set of
options, making it almost unusable for such users.

Certainly, if we want to reach end and novice users, they needn't build
anything.  I want to tell a novice user to "pkg_add foo" and have it
running, not to "install pkgsrc, build foo... wth is build?".  We fail
miserably in this regard.

Just look at all those Linux distributions based on binary packages.
Almost all users are more than happy to install a package with whatever
the maintainer chose to build it with.  In cases where choice is
important, different binary packages are provided.  But other options
are simply ignored because there is little value in having them.

Of course, there are some options that are unavoidable.  But I see these
as system-wise rather than package-specific.  This includes the example
you gave (IPv6) as well as, e.g., cups support, optimization flags, etc.

And there are other "crappy" programs that are not binary-friendly at
all.  One of such examples is mplayer.  Here, options are also valuable
because you have to build it on your own anyway.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/