Re: Building Abiword 3.0.0 fails in build stage

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

On 2014-12-22, at 5:59 PM, Greg Troxel wrote:
> "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost> writes:
> 
>> I think the term "plugin" has perhaps contributed some confusion
>> here. All the "plugins" are part of the base distribution tarball.
>> (Though some of course pull in other dependencies.)
> 
> This didn't confuse me :-)
> 
>> All of them are
>> enabled in base packages distributed by the upstream project,
> 
> Typically, upstream projects expect everyone to build from source,
> rather than targetting packages.

We follow different kinds of upstream projects, I think. ;)

>> as well
>> as in other downstream packages (e.g. in Linux distros). Some are
>> arguably necessary for anything approaching a modern word processor,
>> not "nice to haves". In other words, they should be included by
>> default. Not doing so won't match common practice. (I recall years
>> ago the same consideration was given about the meta-pkgs/gnome-base
>> package, and the decision was that since the upstream project didn't
>> distribute a stripped-down version, neither should pkgsrc. The same
>> principle holds here.)
> 
> I really wasn't trying to argue for a particular outcome.  I was just
> trying to make the point that the decisions about how to deal with what
> is on by default and separate plugin packages should be driven by
> considerations of binary package users.

My assumption would be "everything on" would be most beneficial for
most binary package users.

> 
>> The existing plugins package from my perspective is simply an
>> abitrary distinction that was created by the original packager and
>> maintained all this time. It offers no configurability, it's simply
>> all-or-nothing (well, within the subset of plugins it explicitly
>> enables).
> 
> In a different situation, imagine a package that builds a command-line
> version of some tool, with a small amount of dependencies.  And also
> that one can build a gtk version, and a qt version.  This is a situation
> where separate packages are in order, because making someone install gtk
> or especially qt to get a command-line tool is not reasonable.

Indeed, I've recently had a submission committed that's exactly of
this nature. It was an enhancement to textproc/aiksaurus to enable a
GTK2 version of it (rather than just the command-line tool). A
separate package wasn't created; rather, an option was added to
enable GTK2. I followed other packages that use this approach. (My
exact method wasn't the one chosen by the committer, but their
approach is the same.) This is why I'm confused by your question:
enabling/disabling components with options rather than creating
separate packages seems to be the norm in current pkgsrc, or at
least, it is for the subset of packages I use. I see that chapter 16
of the "pkgsrc Developer's Guide" states the opposite, but that
appears to me to not necessarily match practice. (In the case of the
aiksaurus change, the option is defaulted to off, so a binary user
wouldn't be able to get it.)

> If the abiword situation is that the dependency footprint of the base
> usable package is large, and the incremental footprint of what's needed
> for the default-on extra plugins is minor, and the default-off extra
> plugins are really not of interest, that's fine.  It just hasn't been
> clear that binary package users were being thought about.

I don't follow why binary package users would necessarily be more
concerned about disk space consumption than functionality? For me,
it's the opposite. (This is a word processor we're talking about,
nobody will be installing it on a Vax.)

In any case, I'm not particularly inclined to debate further, as we
now seem to have three people working on the same package at the
same time (if only other packages got such attention!), and if
someone else is going to put in all the elbow grease to get the
package in complete order, I won't argue with their approach. I was
discussing how I think it should be done, if I do it.

Dave