Port approval

[Scott Haneda]

On May 25, 2009, at 8:12 PM, markd at macports.org wrote:

>> Current postfix @2.5.5 Postfix is at 2.6 stable.  I am not sure going
>> to 2.6 from the 2.5.5 is best, perhaps make a new port, as it may  
>> have
>> changed significantly, to where an upgrade one would break a lot. At
>> the very least, we can do 2.5.7, which has significant updates and is
>> I believe, the last release in that branch to date.  I would love to
>> supply this portfile, but need the above pushed out first.
>
> This is where MacPorts differs from other package managers as far as  
> I can
> tell.  That a new release might break stuff is always the case, and  
> not a
> sufficient reason to create multiple versions of the same port (though
> -devel is a standard for non-stable code).  Postfix 2.6.1 is listed as
> stable and so the preference would be to update the port to that or  
> wait
> until a future rev if not possible (reporting trouble to the postfix
> developers in that case).  That said, the postfix port is in desperate
> need of a maintainer, and I'm not at all certain that the portfile  
> is how
> it should be (I wonder if the Makefile could not be used instead of
> xinstalls and such).  I have cleaned it up from a horrible mess in the
> past since no one else did but I wish someone who uses it in  
> production
> would step up and maintain it.


I think that myself and a friend will end up stepping into the  
position of maintaining it.  It does work in the current form now, but  
it takes some fiddling to get it there.  I would have to review my  
notes, IIRC, there are users/groups/permissions, and directories that  
all need to be made to get it working well.  In no way does `port  
install postfix` get you a MTA that is good for more than pointing a  
php script at it.

I brought up the versioning issues on the postfix list.  That list is  
a little bit of walking on eggshells :)  The general idea there, is do  
not upgrade unless you need the new features of the latest stable  
release.  So 2.5.7 contains only non new features of the 2.6 branch,  
but has back revisions of 2.6.x that are bug or security related.  I  
believe that is an accurate summary of what I was told.

That means, to me, that 2.6 is all new features.  That being the case,  
it may not be possible to gracefully go from 2.5 to 2.6, I will have  
to look into it.

Can you elaborate on your comments about using makefile over xinstall?

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.

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.

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 :)

Suggestions, comments?
-- 
Scott * If you contact me off list replace talklists@ with scott@ *