Re: Building Abiword 3.0.0 fails in build stage

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

On 2014-12-22, at 12:04 PM, Greg Troxel wrote:
> Ottavio Caruso <ottavio.caruso%googlemail.com@localhost> writes:
>> On 22 December 2014 at 14:17, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>>> "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost> writes:
>>> 
>>>> I really don't think it's beneficial to have a separate plugins
>>>> package anymore. It makes more sense to integrate the plugins as an
>>>> option within the base package (which is what I've done). As you've
>>>> found, even when "no plugins" is specified, it still builds the one
>>>> that handles ODT documents, so at a minimum the base package will
>>>> install that one, and it'd be confusing to have one plugin coming
>>>> from one package, and others from a separate one.
>>> 
>>> Can you explain how you see this working with binary packages built for
>>> bulk builds (with default options) and users installing them via pkgin
>>> or something?   Which plugins would be default on, and what do people
>>> have to do to get ones that are default off?
>> 
>> The opendocument plugin is builtin with Abiword. To disable it
>> completely one has to specify "--disable-default-plugins".
>> 
>> With "--enable-plugins=yes" one build all plugins for which
>> dependencies are already available (think of an "auto-plugin"
>> feature), otherwise --enable-plugins="foo bar" will compile all
>> specified plugins and will check for dependencies while configuring.
> 
> So how does that lead to a set of binary packages produced by a bulk
> build which are a reasonable tradeoff of having things available and not
> bringing in unreasonable dependencies for the base package?
> 
> I'm not trying to argue that opendocument should be separate.  A world
> where a few plugins that don't hurt much dependency-wise and that almost
> all users want are bundled, and others aren't, is totally fine.
> 
> My point is that options are really not a great plan, because binary
> packages have default options.  If choosing non-default options is very
> odd, then it's fine.  It's also better than not having options if making
> separate packages is infeasible.
> 
> But I'm unclear on how many others there are, and what their dependency
> costs are, and if you propose to have them default on or off.  Really I
> am reacting to the "having separate packages for plugins is pointless"
> notion, because in general it's the right thing to do.

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.) All of them are
enabled in base packages distributed by the upstream project, 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.)

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

> 
> But maybe only two of you use AbiWord anyway, so if you're both content,
> that might be entirely good enough.

I doubt it's a particularly popular package, but I have no idea.

Dave