Port approval

[markd at macports.org]

On May 26, 2009, at 3:05 PM, Scott Haneda wrote:
>Can you elaborate on your comments about using makefile over xinstall?

The portfile has a custom destroot section.  Look at what is between
'destroot {  }'  Normally this is not required and mp simply does a 'make
install' by default.  Not sure if this is really necessary still or a
legacy of an earlier poorly behaved version of postfix.
>
>My next question, while not about postfix, applies perfectly to this 
>thread as well.  For ages now, I am working on an ASSP portfile.  The 
>number of perl depens is huge, the second I get it close, they update 
>ASSP, and a new depens comes along that is not in MacPorts.  Make a 
>new port for that, find it depens on some other, rinse, repeat.  Ugh.

I've seen updates require other modules that haven't been ported too.  But
with perl modules, making ports is as easy as it gets so it isn't as bad
as it sounds.
>
>With all this, I see no possible, conceivable way that the old ASSP 
>port is going to be able to have a `port upgrade assp`.   It can not 
>work.  The only way it could work, would be to riddle the port file 
>with conditions to cover every version of ASSP from then to now, 
>probably 50 revisions.

It is great that you consider the users time and effort, but in my view
you are putting too much emphasis on possible breakage with 'port
upgrade'.  I don't use upgrade that much (so I don't see why it won't work
in this situation), but there are many circumstances beyond our control
that make upgrades difficult or impossible.  If the developer provides no
good way to upgrade, then we should not feel bad about failing to make a
port upgrade by overcoming what the developer could not or did not do.  I
think that it a burden that only makes us responsible for what we have no
responsibility for, and makes it harder for the end users in the end.
>
>To me, sounds like this postfix issue is the same, the original port 
>file was nice to have, someone put in the time to do it, we are all 
>grateful.  A lot has changed since then, to try to keep that portfile 
>relevant moving forward, means a lot more work for a new maintainer.  
>Postfix's portfile may not be that out of date, so keep this more 
>theoretical in discussion that just about postfix.
>
>What do we do in cases where older ports are part of software that 
>changes rapidly, and a huge duration of time has passed with no port 
>update happening.  To me, if the portfile has not been updated close 
>to the update cycle of the software it builds, in a lot of cases, the 
>only logical thing to do would be to "fork" the port, and start clean.
>
>A lot of these ports are "systems".  It is not like awk, sed, nano, 
>tail etc, where you have one small little binary you are messing 
>with.  These "systems" have a binary, but they sit on top of, or next 
>to, user data, users, groups, permissions, scripts.  In cases like 
>that we need a very committed maintainer, who will stick with it.  
>Otherwise, I fear we end up with what I am doing now, making a local 
>port, not worrying about previous ports, and moving on.  Then I 
>distribute that port off list, off project, and the community does not 
>benefit from it.  That is a huge shame, one I do not like to be a part 
>of, but I also do not want to be a part of breaking every postfix mail 
>server out there based on ports :)
>
I agree that some ports are "systems", and that is why I see if any
dependencies of ports I'm updating are out-of-date when I get ready to
update a port and do it or request a maintainer do so.  But even though
they may be "systems" in some sense, we all knew what we were getting into
with modular software to begin with and I guess it still seems to me you
are thinking about shouldering some burdens that the developers have
chosen not to worry about and I think that won't work in the end.  But
maybe I've misunderstood your point here.

On May 26, 2009, at 3:05 PM, Daniel J. Luke wrote:
>I would encourage you to use 2.6.1 (or whatever the latest current  
>stable release is around when you get time to work on it).

I agree.  And often when people say "create a portxx" because there are
some issues on OS X, it turns out that there are issues because no one
tested the new source (or at least reported bugs to the developer) until
the port was updated to the latest.  This happened with rrdtool 1.2 ->
1.3.  It worked for me (so I updated the port) but others had issues.  But
there were quickly reported to the developer by the mp users and fixed,
whereas had the port been relegated to the port-xx ghetto there is no
telling how long it would have taken to get 1.3 de-bugged on OS X. 

Mark