Re: need help making a port for django

Erick Tryzelaar <[email protected]> writes:
>No, thats a good question. It all really depends on MacPorts, and their=20
>policy with backwards compatibility. I ran into this issue before with=20
>another one of my packages, py-scipy. It's unclear how we should go=20
>about updating packages that result in incompatibilities. For the larger=
=20
>projects, such as gtk, it makes sense that we keep around gtk1 while=20
>supporting gtk2. For smaller packages though, it's hard to tell when we=20
>should, and should not, support older versions.
>
>Any of the senior MacPorts folks around to resolve this policy decision?=
=20
>I personally don't mind doing either, I just personally don't want to=20
>make a call that could potentially break other people's stuff. So, could=
=20
>you? :)

I think it is a call that only a person with knowledge of the apps in
question could answer.  It all depends.  But since I think we all prefer
fewer ports because Macs users tend to think simplicity=3Delegance=3Dgood=
, the
preference is clear.  But whether or not we can eliminate port versions
has to do with a distinction between theoretical possibility and practial
probability.  Hard core Unix blokes will always want to make backwards
compatibility work so that *if* someone comes along needing an app that
requires a particular supporting app version it is there.  They really
don't care much if the probability approaches zero that the target
audience will ever do that.  The possibility exists and they want it
covered.

But my sense is that the Mac community is not like this, so I don't see
this as a policy question, but rather a pragmatic case by case one.  The
only overriding principle here for MacPorts I think is simplicity, meanin=
g
as few ports as pragmatically possible given the apps the target audience
is likely to run.  For example, I've knowingly broken some apps
judiciously to not have multiple versions of the same ports when I though=
t
it highly unlike actual current users would be affected.  For example, al=
l
other package managers have two Nagios ports (1.x and 2.x), and two
RRDtool ports (1.0.x and 1.2.x).  For Nagios there never was a 1.x on DP,
for RRDtool, I replaced 1.0.x with 1.2 last summer and in both cases the
newer ones were not backward compatible.  Without dragging through the
details of why I thought this was acceptable in these cases, I can tell
you there have never been any complaints or requests for either older
ports.  I am not surprised, though I knew the theoretical possibility was
there, because I am pretty familiar with the variety of apps requiring
RRDtool and when users needed Nagios 1.2 and when they don't.  My sense
was that the extra ports would not be missed and that there presence woul=
d
generate questions and the need for variants.  It was a judgment call I'm
glad I made because it is better to have fewer ports and Mac users often
expect some guidance that FreeBSD users do not.

>From a "backwards compatibility at all costs" perspective (often seen in
the Unix world) this would be unacceptable.  From a "I really don't think
current Mac users are using X combinations of apps" and one port per app
means simplicity, it made total sense.  Package managers inevitably make
some assumptions for users and this is unavoidable, so I guess the
question is whether is it a practical expectation of yours that there are
users out there needing those 3 ports now, or whether it is just theoreti=
c
possibility.  Because if introducing older port versions along with a new
one on MacPorts where none existed before, the question arises whether or
not any current users of the previous users are out there.

I'm not at all telling you what to do, and I have never heard of Django,
I'm just letting you know what my reasoning has been in *possibly* simila=
r
circumstances so far and how it has worked out.  The circumstances
surrounding Django could well be entirely different.  I hope that helps.

Mark