On 2018/07/11 12:11, Raf Czlonka wrote:
> On Wed, Jul 11, 2018 at 10:26:42AM BST, Stuart Henderson wrote:
> > On 2018/07/11 10:15, Raf Czlonka wrote:
> > > On Wed, Jul 11, 2018 at 09:24:56AM BST, Stuart Henderson wrote:
> > > > On 2018/07/07 23:00, Raf Czlonka wrote:
> > > > > On Sat, Jul 07, 2018 at 12:40:47AM BST, Stuart Henderson wrote:
> > > > > > [...]
> > > > > > +BUILD_DEPENDS = ${RUN_DEPENDS-main}
> > > > > > +LIB_DEPENDS-main = converters/libiconv
> > > > > > +RUN_DEPENDS-main = mail/abook
> > > > >
> > > > > There's not need for abook to be a run dependency - m_abook module
> > > > > is only usable if it is both specified in METHODS *and* abook
> > > > > executable present, ignored otherwise.
> > > >
> > > > It's a really small dependency though, and the only extra thing it pulls
> > > > in is gettext which mutt users will have anyway, so I don't see a lot
> > > > of point
> > > > in /not/ including it, it does make things more consistent.
> > >
> > > Sure - however, I was thinking ahead.
> > >
> > > I.e., the latest version of lbdb has goobook[0] and khard[1] modules.
> > > Personally, I don't think each and every program which *enhances*
> > > lbdb, should be a hard dependency. Even in Debian all of these are
> > > only *suggested* packages[2]. Personally, I don't even think that
> > > the -ldap flavor is necessary - a pkg-readme with all the optional
> > > packages, i.e.:
> > >
> > > - Net::LDAP
> > > - abook
> > > - goobook
> > > - khard, which would pull vdirsyncer
> > > - ...
> > >
> > > would suffice, IMO.
> > >
> > > This would:
> > >
> > > - remove the need for hard dependencies so no extra software, which
> > > otherwise would potentially not have been used, needs to be
> > > installed
> > >
> > > - if LDAP support is "merged" to the main flavor, there's one less
> > > flavor to maintain
> > >
> > > - any additional *enhancement* are added to the readme
> > >
> > > It somehow feels simpler and easier.
> > >
> > > Otherwise we'll end up with two packages, where they pull 3-4
> > > additional programs and the only difference is that one pull an an
> > > extra Perl module.
> > >
> > > Don't some ports already do just that?
> > >
> > > Or we go the other way and each and we add each and every of these as
> > > hard dependencies but the chain grows...
> > >
> > > Anyway, food for thought :^)
> >
> > -ldap is a multi package rather than a flavour, it contains only the
> > additional files produced when ldap is enabled rather than being an
> > "either/or" thing.
> >
> > The usual procedure with "modular" ports using multi packages is to
> > include things with lightweight/no extra dependencies directly in the
> > main package, and place things with heavier dependencies in a subpackage.
> >
> > > [0] https://pypi.org/project/goobook/
> > > [1] https://github.com/scheibler/khard
> > > [2] https://packages.debian.org/sid/lbdb
> >
> > I think these would be good candidates for additional multi packages.
> > While we *could* merge them into the main package and add a README telling
> > people how to actually use them, it's a lot more convenient for the user
> > to just run pkg_add once.
> >
> > It's a pain to have a proliferation of flavours as they have to be tested
> > separately. Multi packages are simple in this respect, there's only a single
> > build run, it produces the same resulting set of packages every time, and
> > if you're working from ports and want to install the whole lot you can just
> > do "make install-all".
>
> Right - confusion between flavor and multi-package on my part. Sorry
> for the noise.
>
> In that case, would the extra subpackages be -abook, -goobook,
> -khard, i.e. so that an individual using one or two of these, doesn't
> have to pull dependencies for all of them?
>
> R.
-abook is such a lightweight dependency I don't think it's worth making
it a separate package.
If adding -goobook and -khard they are a bit heavier, so splitting them
would make sense to me.
