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?
>
> 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.)
>
>
> > 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?
>
> 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.
>
> 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.
>
>
>
> > If I can only get one answer, question 2 would be far preferred.
> > Any help better than copy/paste would be great.
> > I would like to move beyond the idiot level of porting.
> > I want to fully understand the answer to question 1 by looking at the
> > OpenBSD porting code and knowing also what is done a certain way:
> > "just because that's SOP, no intrinsic reason"
> >
> >
> > BUILD_DEPENDS = devel/p5-Test-Compile>=1.2.1 \
> > devel/p5-Test-Pod>=1.48
> >
> > RUN_DEPENDS = devel/p5-Algorithm-Diff>=1.1903 \
> > devel/p5-Test-Compile>=1.2.1 \
> > devel/p5-Test-Pod>=1.48 \
> > textproc/p5-Regexp-Common>=201331301
> >
> > TEST_DEPENDS = devel/p5-Test-Pod>=1.48
> >
> > --
> > Chris Bennett
> >
> >
>
> --
> andrew
>
> At the source of every error which is blamed on the computer, you
> will find at least two human errors, including the error of blaming
> it on the computer.
--
Thanks,
Chris
