Re: options.mk descriptions questions

[Kevin Bloom <kevin.bloom%posteo.net@localhost>]

> The basic rule of thumb is that options are bad, but sometimes they are
> better than not having options.  Binary packages are (in theory; not all
> bulk builds comply) built with a near-empty mk.conf and thus with
> default options.  At least, that's the rule for what's on
> ftp.netbsd.org.  So, what matters most is what the default is.  Beyond
> that, odd things can be be default-off, and people who are unusual can
> choose to disable things that are default-on.

Okay, makes sense.

> I find it irregular to have an option that controls other options.  I
> don't think we really do that.

Noted.

> Yes, we can have another package, probably sharing Makefile.common.  But
> the question is; do reasonable people actually want this, or is it
> merely possible?  The world is too complicated, and if we can just
> choose not to engage in some complexity, and nobody is harmed (or few
> are harmed much), the rest of us not dealing with it might be a win.

Yeah, I don't know any one that uses this editor. I'm mostly using it
as a way to learn more about the options.mk stuff. Plus, it's nice to have
some alternatives to normal Emacs. The more the merrier, right? I'll just
leave out the tiny option for now and just make it so that if you don't have
the X11 stuff enabled it'll just do a tiny build that way.

> I think it's that you get someone to add them there, perhaps by just
> putting an options.description file in the package with the lines.  This
> doesn't happen that often so we don't have a formal plan for wip.

I'm not going to worry about it since it'll only have 1 option: x11.

> Normally we have options when there is a dependency. Like adding qt5 to
> something small.  For html, what is the cost of having it?  Would
> anybody really need to save 20 kB of program text?  Just because
> upstream lets you disable it doesn't mean pkgsrc should accept that
> complexity.

Makes sense to me.

> For png, xshm, xv, the dependencies are confusing.  The normal approach
> is to put the CONFIGURE_ARGS first, a blank line and then the bl3,
> mirroring Makefile.  Not a big deal but I managed to read it wrong.

My mistake, I think I looked at www/firefox as an example and that's how it
was done.

> It more or less looks to me like x11 has to be on if several of the
> others are.  As it is, with png, the png bl3 is included but libX11's is
> not.  So:
> 
>   perhaps have a "if png is in the options var and x11 isn't, force on
>   x11"
> 
>   perhaps similar logic, but error.
> 
> It feels like we must have this problem elsewhere.  I lean to error if
> wrong and make people fix, and less magic, because magic is hard to
> debug.
> 
> I would ask: once you add x11, how much does it hurt to add png and
> xshmfence?  That's a combination of
> 
>   how many bytes of additional installed packages are required?
> 
>   how many bytes beyond what would have been anyway, average over many
>   systems?
> 
>   how long does it take to build from source because of that, compared
>   to what it takes anyway?
> 
> My gut feel is that once you go to X, because you are on a system that
> does GUI things, libpng is just not going to hurt.  Overall that leads
> to 
> 
>   always enable plugins (no option)
>   always enable html (no option)
>   having an x11 option that turns on all the x11 things.
> 

I think your logic is sound and I agree that enabling those things makes
sense. I'm leaning towards not enabling ffmpeg, xshm, or xv by default and
NOT having options to turn them on. I don't see their benefit nor do
I understand how the editor uses them.

> Overall my advice is only add options when there's a clear win to
> control it on/off.  Otherwise choose, leaning to having a feature rather
> than not, as a little code you don't want is less painful than having to
> rebuild.  Unless the code is objectionable/scary.  In the end, it
> depends!

Got it.


Thanks for your in-depth explanation, Greg.