Removing negative variants from alpine (Was: [MacPorts] #38091: alpine @2.00_4: update to 2.11)

[Lawrence Velázquez]

On Feb 25, 2015, at 9:49 PM, MacPorts <noreply at macports.org> wrote:

> #38091: alpine @2.00_4: update to 2.11
> -----------------------+----------------------
>  Reporter:  larryv@…  |      Owner:  john@…
>      Type:  update    |     Status:  closed
>  Priority:  Normal    |  Milestone:
> Component:  ports     |    Version:
> Resolution:  fixed     |   Keywords:  haspatch
>      Port:  alpine    |
> -----------------------+----------------------
> 
> Comment (by jerryyhom@…):
> 
> OK, humor me while I try to understand your reply.  Essentially, your
> considerable efforts are to transition the portfile to explicit positive
> variants while maintaining compatible behavior; after about a year, you
> will remove the transitional code, completing the transformation to
> explicit positive variants; everything is virtually identical.  Please
> correct me if my summary is wrong.

Exactly right. It wasn’t that much effort; I’ve done this several times
before.


> Now, hopefully these are received as constructive comments.  Please
> understand, my mindset is in trying to simplify and enhance alpine's
> portfile.  On one hand, your changes seemed to go the other way and
> complicate it

Of course simplicity for the maintainers is important, but this port
does not exist in a vacuum. More important than simplicity for its own
sake is consistency with other ports. Negative variants have been
verboten in MacPorts for years, and allowing them to remain in this one
port would make MacPorts as a whole less coherent.

For instance, one of MacPorts’ useful behaviors is that variant
selection can propagate to dependencies. A user with no ports installed
who installs `alpine -kerberos` would thus get `cyrus-sasl2 -kerberos`
installed also, thus avoiding an unnecessary installation of `kerberos5`
(unless `cyrus-sasl2` were already installed). Maintaining the negative
variants disrupts this.


> Generally, your explanation in your first paragraph probably belongs in
> the Guide.  The portfile recipes and perhaps many parts of the wiki could
> go in the Guide.

Probably, but I don’t have time to write polished documentation.


> Alpine specific, since you are cleaning up some depends_libs, the only
> depends_lib necessary is openssl, at least on my 10.9 system.  In fact,
> because the upstream code does not conditionally code around it, the
> --without-ssl option (and variant) is useless, and probably no one has
> tried and complained.  The libs iconv and ncurses are already provided by
> OS X; if not on older systems, they could be conditional, but probably a
> minor point here.

We don't use system libraries.

https://trac.macports.org/wiki/FAQ#syslibs


> Alpine builds on my system without gettext, but also probably a minor
> point.

If a piece of software can use gettext, we generally add it as an
unconditional dependency.


> When or why did the without_tcl variant become obsolete?  Do you mean
> because MP implicitly has Tcl that the variant is obsolete?  Your comment
> in the portfile is unclear.

The variant is obsolete because I made *all* negative variants are
obsolete. A user who wants to build Alpine without Tcl support should
install `alpine -tcl`, not `alpine +without_tcl`.

I left a comment in the `tcl` variant because merely removing the
`--without-tcl` configure option doesn't tell the configure script where
to find Tcl. This suggests that it simply uses whichever Tcl it finds,
which isn't usually desired behavior. I don't really know how Alpine
uses Tcl, so I don't know what the correct course of action is.


> Two more comments which tie together.  Overall, more commenting would
> help, either in the portfile or descriptions about your changesets.  You
> are experienced, know what you are doing, and if you were the only one
> looking at the code, you would easily go on doing fine work.  However as
> you know, portfiles are under scrutiny by others, usually maintainers.  Of
> course, you may do as you like as a committer, but as MP is a distributed
> management system, please be more mindful of others reading your code.

I'd be glad to add more comments if it helps.


> I am trying to learn MP, but I am learning that the role of maintainer
> is easily trampled over by committers.

I don't want you to feel like you're being trodden on, but avoiding
negative variants is a very strong convention in MacPorts by now, and
I don't think migrating a port away from them should be a contentious
change. If you need further help keeping `alpine` working correctly, I'd
be more than happy to provide it.


vq


> Ticket URL: <https://trac.macports.org/ticket/38091#comment:39>
> MacPorts <https://www.macports.org/>
> Ports system for OS X