On May 25, 2009, at 8:12 PM, [email protected] 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@ *
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
