On Tue, Dec 14, 2021 at 11:30:31AM -0800, Chris Bennett wrote:
> On Tue, Dec 14, 2021 at 10:17:43AM -0800, Andrew Hewus Fresh wrote:
> > I really don't follow quite what "something like this" is, so I'm
> > probably going to answer the wrong question.
> >
> > My guess as to the question is, how do you decide what to put into the
> > different *_DEPENDS?
>
> Close enough and a good set of answers.
> One question was how to properly deal with BUILD_DEPENDS having two of
> the same depends that RUN_DEPENDS has.
> Assuming that build and run must have those two, but that the extra
> RUN_DEPENDS are only for running and not for building.
> (Which I'm able to ask more properly after this reply from you, thanks)
>
> Leave as-is?
RUN_DEPENDS don't get installed during BUILD and BUILD_DEPENDS don't get
installed during RUN, so if it's needed in both places it needs to be in
both places.
I usually comment-out the "extra" BUILD_DEPENDS, remove them and see if
it still builds and test pass. For perl ports this is usually fine and
failures are obvious, and as I said, the "extra" BUILD_DEPENDS are
usually because previously perl didn't have the concept of TEST_DEPENDS.
portgen has some magic to move things that match "Test" to the
TEST_DEPENDS because it is so common. For things that aren't perl, it
depends.
> >
> > For perl ports, I generally start with what the author added to their
> > META files, which is reflected in what portgen(1) does. It used to be
> > perl didn't separate BUILD from TEST depends, so lots of modules still
> > don't do that, so sometimes it makes sense to move them around.
>
> Helpful. I have a sneaking suspicion that understanding the perl
> building process may require knowing what was done in the past, in order to
> understand what and why the present is the way it is now.
> (I.E. my father had to learn the past government regulations in order to
> make any sense of what the new regulations were for a job he had.
> Despite the fact that the old regulations were gone, but influential to
> the new.)
There are a few, primarily due to trying to replace MakeMaker, but most of
that knowledge is not needed often.
> > > 2. More important, why is that the right way?
> > > I would like to know where to look in which code for ports process to
> > > get a better understanding of how this plays out.
> >
> > This is not "official", but it is my best practices for what to put in
> > each of these.
> >
> > BUILD_DEPENDS are the minimum list of dependencies needed to
> > successfully and repeatable build a package. The fewer you can have,
> > the faster bulk builds go.
>
> So if there are no build depends other then the port itself, this would
> be left out?
> But if there are run depends in order to use it only, would
> BUILD_DEPENDS=${RUN_DEPENDS} get used or not?
If it will build without, leave it out.
(If it builds differently, that's a different matter)
Usually BUILD_DEPENDS=${RUN_DEPENDS} is unnecessary, but some things
check for dependencies before they will do the build.
> >
> > TEST_DEPENDS are the maximum list of dependencies to get the best test
> > coverage. Sometimes it isn't worth porting a whole set of extra
> > dependencies just for a single optional test, so there is a balance.
>
> I had a port committed that needed one single line from
> print/texlive/texmf,-full for testing.
>
> I see you are the maintainer now for it. p5-LaTeX-Driver
> That is a requirement for the few perl ports that didn't get in for
> LedgerSMB a long time ago.
Good tests are hard to write and sometimes mean you need a big
dependency. Usually it's only the person doing updates that runs the
tests at the moment so large dependencies there aren't a significant
problem, although if I had unlimited free time I'd have a ports-tree
smoker.
>
> >
> > RUN_DEPENDS are the dependencies that give the person installing the
> > best experience. If there is some large dependency that is for a seldom
> > used feature that has useful error messages that make it clear you need
> > to install additional dependencies if you try to use it, then you
> > probably can leave it out. Otherwise, if it makes the port more usable,
> > probably add it.
>
> I had a port submitted (can't remember if it was committed),which had no
> run dependencies, but I was advised to add a message to note which
> packages ought to be added in order to make any use of it.
>
> So this would be the motivation for something like neomutt and
> neomutt-notmuch. Most people would just use neomutt, but enough people
> also want notmuch included, that adding a flavor was worth it.
Correct, sometimes a flavor is worth it, just for dependencies.
--
andrew
($do || !$do) && undef($try) ; # Master of Perl, Yoda is. Hmmmm?
