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.
