alpine @2.00_4: update to 2.11

[larryv (Lawrence Velázquez)]

​Alpine 2.10 has been released. We should probably update the alpine port.

[jummo4@…]

I have successfully installed Alpine 2.10 on my 10.8 system with the attached patch.

[macports.org@…]

Alpine 2.11 has been released.

​http://patches.freeiz.com/alpine/release/

[jummo4@…]

I have added a patch for Alpine 2.11.

[jummo4@…]

Cc Me!

[patrick.sizun@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

This does not build for me. I tested on 10.6, 10.7, 10.8, 10.9 and each time got an error like this:

Undefined symbols:
  "_libintl_setlocale", referenced from:
      _set_collation in libpithosd.a(collate.o)
ld: symbol(s) not found

[SickTeddyBear]

Cc Me!

[jerryyhom]

Hello! I would like to see the alpine port updated to 2.11. I grabbed the sources from Eduardo Chappa’s site, made a patch for the Portfile and updated an existing patch for the alpine sources, and have built it on 10.9. The patches should be attached.

I looked into and wanted to clean up the patches. The 2.11 sources seem to need only the patch for INTLLIBS which I updated. I also made the patch from the sources’ top-level directory, so patch.pre-args should no longer be needed. The osx-10.6 patch is already in the sources. I think the configure patch is now handled in the current configure script. The imap Makefile patch seems redundant since MacPorts already has ${prefix} and uses it in configure.args. I would appreciate any feedback.

I know the alpine port hasn’t had a maintainer in a while and John recently volunteered. I would also volunteer as co-maintainer if you don’t mind. I think the Portfile could be cleaned up a bit more, but for now I tried the minimum for building.

[larryv (Lawrence Velázquez)]

Replying to jerryyhom@…:

I know the alpine port hasn’t had a maintainer in a while and John recently volunteered. I would also volunteer as co-maintainer if you don’t mind.

If John is okay with it.

[jcvernaleo (John C. Vernaleo)]

I'm totally fine with a co-maintainer.

As for the update, going to test build on my machine now and will replay back real soon.

[jcvernaleo (John C. Vernaleo)]

jerryyhom@ couple minor issues with the Porfile you attached.

master_sites ​http://patches.freeiz.com/alpine/patches/alpine-2.11/alpine-2.11.tar.xz

That should not have the file name in it (and really should not have any version number in it). I think the correct path should be: master_sites ​http://patches.freeiz.com/alpine/release/src/

since that is more generic.

Also, the patch file alpine-2.00_panic_rename.patch is still needed for Yosemite.

Could you make those changes and let me know if it still builds okay on your system (10.9 I think you said).

Thanks!

[jerryyhom]

Oops, I misunderstood the use of master_sites; simple fix, and thanks.

Re: the master_sites path, could you clarify what you mean by “more generic”? There are two source codes involved here.

I will work on the panic rename patch.

[jcvernaleo (John C. Vernaleo)]

Sorry for not being clearer. By 'more generic' I just meant that it should not have the version in it, but you said you fixed that so don't worry about the 'more generic' comment.

Once you post the updated Portfile I'll test it out and hopefully we can get it in then.

[jerryyhom]

Hm, I agree with you about going for more generic, except that in this case, Chappa created his path structure that way and his source codes all seem to be in different places. Anyhow, I thought you might have been talking about using plain 2.11 (which seems to be 2.00 with bug fixes) or 2.11 plus Chappa’s patches/features. Assuming the latter, I am attaching the Portfile patch along with the two accompanying patches. Thanks for testing.

[jcvernaleo (John C. Vernaleo)]

What about:

master_sites ​http://patches.freeiz.com/alpine/patches/

distname ${name}-${version}/${name}-${version}

I don't like having the version number hardcoded into the master_sites variable since that isn't really what master sites is for. This way one can update this with less changes.

Other than that looks great to me.

[jerryyhom]

Okay that works. I made one other change to make the yosemite patch apply only to yosemite. It’s a reminder to me that whenever 10.11 comes out, we’ll see if it was an anomaly or stable change on Apple’s part.

[jcvernaleo (John C. Vernaleo)]

Sorry for the slow reply. Busy weekend.

Based on past experience, that change is unlikely to be temporary, but I'm fine with leaving it as you have it.

So let's get these changes in.

[larryv (Lawrence Velázquez)]

I’ll look at this soon-ish. There are a couple of changes that I’d like to add, to take advantage of the version bump.

[jcvernaleo (John C. Vernaleo)]

larryv. Awesome, thanks!

[macports.org@…]

Eduardo Chappa has now released 2.20.

[jcvernaleo (John C. Vernaleo)]

Replying to macports.org@…:

Eduardo Chappa has now released 2.20.

While new version always excite me, I think we should ignore that until after we have 2.11 in.

[jerryyhom]

Replying to macports.org@…:

Eduardo Chappa has now released 2.20.

Heh, great! Upstream bug fix simplifies our work by eliminating a patch... I should have just waited two weeks...

[jerryyhom]

Among the several new features of alpine 2.20, one bonus which helps ports (including Homebrew and Fink) is the added configure support for testing alternate paths. The portfile could be simplified by eliminating about 25 lines, mostly configure options. The Makefile patch is now included upstream. Plus, in a nod to Yosemite (and maybe other systems), panic() has been renamed to alpine_panic() upstream. So alpine 2.20 should just build out of the box.

[larryv (Lawrence Velázquez)]

Could you attach a patch for 2.20 then?

[jcvernaleo (John C. Vernaleo)]

First thing tomorrow morning I'll update the patch for the Makefile.

[jerryyhom]

Replying to larryv@…:

Could you attach a patch for 2.20 then?

I am attaching a portfile patch for 2.20 with minimum changes. The ssl related configure and build options are redundant and could be eliminated in the future. I think most of the other configure options are redundant too, but maybe there are historical reasons. I built it manually with no options against both openssl/libressl. Also, the 2.20 portfile should not need any patchfiles.

[jcvernaleo (John C. Vernaleo)]

Looks good to me. larryv, I'm happy for that list diff to be committed and all the patches removed.

[jerryyhom]

The checksum for the distfile may be changing while keeping the same filename because Chappa realized an important typo in his documentation. He has already updated his website docs, and I expect the distfile will update soon.

[jcvernaleo (John C. Vernaleo)]

Changing files without changing versions is very very bad practice. I guess we can wait for that update to commit, but I really think we need to just go with what we have after that regardless of ANY other updates.

[jerryyhom]

Yes, it is bad and just means more work for us. I am attaching the new portfile patch with updated checksums.

[jcvernaleo (John C. Vernaleo)]

Great. larryv feel free to commit that (and delete the patches) when you get a chance.

[jerryyhom]

updated checksums

[larryv (Lawrence Velázquez)]

It looks like you’re using the ​fully-patched source instead of the ​unpatched source. This is not workable because the distfile name does not change with the patchlevel. If upstream changes the patchlevel, users will start seeing checksum mismatches.

If we use the ​unpatched release, could we still remove all of our patches? Would your portfile patch still be valid (checksums aside)?

[jerryyhom]

OK, I'll check the sourches without Chappa's patches. Thanks for the explanation.

I'm fairly certain the MacPorts patches can be removed because they deal with configuration issues and the panic() symbol clash which have been incorporated upstream.

[jerryyhom]

I have built the plain sources and updated the portfile patch. Nothing new to report. Please have a try.

[jerryyhom]

plain sources

[larryv (Lawrence Velázquez)]

These should take care of everything. Let me know if I broke anything, especially with r133173.

• r133171: New co-maintainer.
• r133172: New homepage.
• r133173: Deprecate negative variants.
• r133174: Update to 2.20.

[jerryyhom]

Finally, alpine is available again to MP users; thanks Larry!

Re: [133173], considering I am new to MP, and I mean no disrespect, could you explain why transposing negative variants into positive ones is helpful here?

From a maintainer's perspective, feels like the changes introduce byzantine rules. At first, I thought it was simply double negatives to positive, but after hours of scratching my head, it seems more like triple negatives to keep the same build behavior? I am losing count, is it quadruple negatives? Overall, seems unnecessary and obfuscating.

[larryv (Lawrence Velázquez)]

Replying to jerryyhom@…:

Re: [133173], considering I am new to MP, and I mean no disrespect, could you explain why transposing negative variants into positive ones is helpful here?

See the final paragraph of PortfileRecipes#default_variants. We want the act of enabling variants to enable features, not disable them. An implementation bug was the only reason negative variants were ever necessary. The vast majority of ports no longer have negative variants; alpine was just neglected until now. Today, the correct way to enable optional features by default is with the default_variants portfile option.

From a maintainer's perspective, feels like the changes introduce byzantine rules. At first, I thought it was simply double negatives to positive, but after hours of scratching my head, it seems more like triple negatives to keep the same build behavior? I am losing count, is it quadruple negatives? Overall, seems unnecessary and obfuscating.

It’s only the transitional code that’s confusing. The logic of positive variants is actually much less confusing than that of negative variants.

• Since the without_tcl variant is deprecated, it should no longer be a default variant.

  dports/mail/alpine/Portfile

  @@ -34 +34 @@
       reinplace "s|__PREFIX__|${prefix}|" ${worksrcpath}/imap/Makefile
   }
   
  -default_variants    +without_tcl
  -

• Without any variants selected, the port should have the minimal possible set of dependencies.

  dports/mail/alpine/Portfile

  @@ -39 @@
  -depends_lib         port:openssl \
  +depends_lib         port:gettext \
                       port:libiconv \
  -                    port:gettext \
  -                    port:openldap \
  -                    port:ncurses \
  -                    port:cyrus-sasl2
  +                    port:ncurses

• Some build systems automatically enable optional features if they detect that the necessary dependencies are present. This is not acceptable to us, as it makes the builds irreproducible. The port needs to explicitly disable optional features if the variants that enable those optional features are not selected.

  dports/mail/alpine/Portfile

  @@ -53 +48 @@
                       --with-ssl-include-dir=${prefix}/include/openssl \
                       --with-ssl-lib-dir=${prefix}/lib \
                       --with-local-password-cache-method \
  -                    --with-debug-level=0
  +                    --with-debug-level=0 \
  +                    --without-krb5 \
  +                    --without-ldap \
  +                    --without-ssl \
  +                    --without-tcl
   
   variant universal {}
   
   use_parallel_build  no
  +build.env           SSLTYPE=none
   build.args          CC=${configure.cc} \
                       EXTRACFLAGS="[get_canonical_archflags cc]" \
                       EXTRALDFLAGS="[get_canonical_archflags ld]" \

• We turn the negative variants into dummy variants but keep them around for migration purposes. We usually give users about a year to upgrade their ports and switch over; then we remove the old stuff.

  dports/mail/alpine/Portfile

  @@ -65 +65 @@
   
  -variant without_krb5 description {Disable Kerberos5 support} {
  -    depends_lib-delete      port:cyrus-sasl2
  -    configure.args-append   --without-krb5
  -}
  -
  -variant without_ldap description {Disable LDAP support} {
  -    depends_lib-delete      port:openldap
  -    configure.args-append   --without-ldap
  -}
  -
  -variant without_ssl description {Disable SSL support} {
  -    depends_lib-delete      port:openssl
  -    configure.args-append   --without-ssl
  -    build.env-append        SSLTYPE=none
  -}
  -
  -variant without_tcl description {Disable TCL support (disables Alpine Web)} {
  -    configure.args-append   --without-tcl
  -}
  +# TODO: Remove legacy variants after 2016-02-20.
  +
  +variant without_krb5 conflicts kerberos description {Legacy variant} {}
  +variant without_ldap conflicts ldap description {Legacy variant} {}
  +variant without_ssl conflicts ssl description {Legacy variant} {}
  +variant without_tcl conflicts tcl description {Legacy variant} {}
   

• Users who already have alpine installed need to be migrated to the new variants in a sane way. Ideally, we’d just set default_variants +kerberos +ldap +ssl and be done with it, but that would cause variant conflicts for users who have alpine installed with +without_krb5, +without_ldap, or +without_ssl. So we only set new default variants if the user doesn’t already have one of the old ones selected.

  I know this is confusing. Think about the first conditional. If a user has alpine +without_krb5 installed, we don’t want to set +kerberos as a default for them because they’ve already explicitly chosen to forego Kerberos support. So we only make +kerberos a default if they have not set the without_krb5 variant. The same goes for the rest. (We have to treat without_tcl / tcl a little differently because +without_tcl was the previous default.)

  The logical contortions one has to endure to reason about negative variants (“if {![variant_isset without_ldap]}”? what?) are actually a very good argument against their use. In any case, you need not worry about it, as it’s only transitional.

  dports/mail/alpine/Portfile

  @@ +73 @@
  +# TODO: Replace this morass after 2016-02-20.
  +#default_variants    +kerberos +ldap +ssl
  +
  +if {![variant_isset without_krb5]} {
  +    default_variants +kerberos
  +}
  +if {![variant_isset without_ldap]} {
  +    default_variants +ldap
  +}
  +if {![variant_isset without_ssl]} {
  +    default_variants +ssl
  +}
  +if {![variant_isset tcl]} {
  +    default_variants +without_tcl
  +}
  +if {![variant_isset without_tcl]} {
  +    default_variants +tcl
  +}
  +
   variant passfile description {Enable password files support} {
       configure.args-delete   --with-local-password-cache-method
       configure.args-append   --with-passfile=".pine.pwd"
   }

• Finally, the positive variants modify the default port configuration to enable the features they control. Unfortunately, Alpine’s build system disables features using negative options, so we end up having to delete them to enable the features.

  dports/mail/alpine/Portfile

  @@ -86 +92 @@
   variant passfile description {Enable password files support} {
       configure.args-delete   --with-local-password-cache-method
       configure.args-append   --with-passfile=".pine.pwd"
   }
  +
  +variant kerberos description {Kerberos support} {
  +    depends_lib-append      port:cyrus-sasl2
  +    configure.args-delete   --without-krb5
  +}
  +
  +variant ldap description {LDAP support} {
  +    depends_lib-append      port:openldap
  +    configure.args-delete   --without-ldap
  +}
  +
  +variant ssl description {OpenSSL support} {
  +    depends_lib-append      port:openssl
  +    configure.args-delete   --without-ssl
  +    build.env-delete        SSLTYPE=none
  +}
  +
  +variant tcl description {Tcl support (required by Alpine Web} {
  +    # Should we force MacPorts' Tcl?
  +    configure.args-delete   --without-tcl
  +}

[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.

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, but on the other hand, I think you could have saved yourself some time. Let me know if we should discuss this directly via email and off this ticket.

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.

Alpine specific, since you are cleaning up some depends_libs, I think all depends_libs may be removed. 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. Alpine builds on my system without gettext, but also probably a minor point. The openssl lib for the --without-ssl option (and variant) is tricky. Building that variant by itself will fail because the upstream code does not conditionally code around all parts. Adding --without-tcl will succeed. Probably no one has tried and compained, but if someone wanted the -ssl+tcl variants, that would fail.

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.

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 am trying to learn MP, but I am learning that the role of maintainer is easily trampled over by committers.

[larryv (Lawrence Velázquez)]

Replying to 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.

Let me know if we should discuss this directly via email and off this ticket.

Yes, this is very much off-topic. I will start a thread on macports-dev.

[larryv (Lawrence Velázquez)]

Replying to jerryyhom@…:

The openssl lib for the --without-ssl option (and variant) is tricky. Building that variant by itself will fail because the upstream code does not conditionally code around all parts. Adding --without-tcl will succeed. Probably no one has tried and compained, but if someone wanted the -ssl+tcl variants, that would fail.

I don’t follow. The --without-ssl configure option requires --without-tcl also?

[jerryyhom]

I am guessing that not many people use the -ssl/+tcl variant and so is probably not worth worrying about. But, if someone complains, here's the issue. Compiling +tcl will try linking with ssl libs irrespective of -ssl. However, if suitable ssl libs are installed, compiling +tcl may succeed, irrespective of -ssl.

[larryv (Lawrence Velázquez)]

Replying to jerryyhom@…:

I am guessing that not many people use the -ssl/+tcl variant and so is probably not worth worrying about. But, if someone complains, here's the issue. Compiling +tcl will try linking with ssl libs irrespective of -ssl. However, if suitable ssl libs are installed, compiling +tcl may succeed, irrespective of -ssl.

Okay, that’s not good. We should make +tcl require +ssl, then.

Does Alpine’s Tcl support actually use OpenSSL, or is it a bug? Has it been reported upstream?

[jerryyhom]

I think it does use ssl and is not a bug, but I am just reporting from my compilation tests.

[larryv (Lawrence Velázquez)]

There are actually further issues with the current port. I’ll open new tickets for them.