Release 1.5 branch created

[Anders F Björklund]

Juan Manuel Palacios wrote:

>> Depends on if you want FreeBSD to still work or not ?
>> Just seems strange to leave it in the "undead" state,
>> either it's revived again or it's properly buried :-)
>
> 	The only reason why FreeBSD support was "left behind", as opposed to 
> flat out pulled, is that at the time no one seemed to be using 
> (Darwin)MacPorts on any platform other than Mac OS X (not even on 
> [pure | open]Darwin), which seems logical to me as most other 
> platforms already have their own packaging tools/ports trees best 
> suited for them. So the question was: why should we be putting <some 
> amount> of energy into supporting scenarios (MacPorts on another 
> platforms) that not only will have a very limited audience, but also 
> that people are likely to choose against? (seems logical to me that 
> they'd choose their own platform's packaging system/ports tree).

Sure, and either way makes sense - keeping it portable or
focussing just on a single os platform for simplicity...
Just that the code had all the "platforms" stuff left in ?

So my impression that it was still portable, just out-of-synch.

> 	So the support was "left behind" due to a sort of generalized lack of 
> interest. But it was not "voted against", we never deemed it as 
> something we would be fundamentally opposed to, as long as there's 
> someone interested enough in the support to provide it him/her-self... 
> like you have in this case ;-) What we did agree on was, seeing 
> MacPorts on other platforms was almost not a real life thing, that on 
> refocusing solely on Mac OS X we would not stop ourselves from using 
> whatever Mac OS X specific technologies we could get our hands on to 
> improve MacPorts just for the sake of keeping it portable...

Portability is just one aspect, while user's freedom is another.
Relying on proprietary Mac things like Xcode or Cocoa will kill
any portability dead anyway, so then the whole issue is moot...

This is also why I think a Darwin or FreeBSD "base" is important ?

> just to safeguard a portability that practically no one was leveraging 
> in real life (again, with good reason in my opinion) and possibly miss 
> out on pretty cool things Mac OS X has to offer. The inclusion of the 
> tcl-objc bridge is an example of this.... but, again, there's no 
> fundamental opposition to portability, I believe. So if someone 
> interested enough, like you ;-), comes along to hook up the bridge 
> with GNUStep to make i work on other than Mac OS X, then big woot for 
> that!
>
> 	As team manager, I have no opposition to merging this set of changes 
> into the release_1_5 branch and shipping MacPorts 1.5 with FreeBSD 
> support again, as long as the code is stable and doesn't cause any 
> failures/regressions on Mac OS X, our by far main focus (cf. my 
> previous question on stability).

There's sure to be some objections like "why can't this
Darwin-only patch go on always" or "why can't I hardcode
these path values that work just fine on my Tiger box"...

One could argue that those are poor practices either way.

>> If it's just crazy old me, I can patch in here locally.
>> I'm not a die-hard FreeBSD fan, I just find the whole
>> Mac lock-in part a bit scary and want to stay portable...
>
> 	I understand portability and love it and embrace it (this is ports 
> tree of open source software after all, and I dedicate quite a bit of 
> time to it ;-), so I understand your concern. But in this particular 
> case I do have to ask: what does portability buy not only the MacPorts 
> project... but MacPorts users themselves? Are they really gonna fire 
> up a FreeBSD box, remove its native (and much larger) ports tree and 
> use MacPorts? I guess I just don't understand the motivation for that 
> (maybe I haven't used FreeBSD's ports tree enough, if you know what I 
> mean ;-).

You mean just like one deletes Installer.app on Mac OS X ? ;-)
MacPorts is just an optional install, in its own little prefix -
it doesn't mess about (much) with the /usr or /usr/local trees.

> But if there is an audience out there wanting to do exactly that, then 
> by all means! Still, however, Mac OS X is by far our main focus and I 
> want to safeguard that. So I guess I could simply sum-up my position 
> as follows: "whatever you want, as long as it doesn't hurt our Mac OS 
> X focus in any way.... and also as long as it's not crack smoking!" 
> ;-) And that goes for other platforms too, not just FreeBSD (someone 
> using MacPorts on Linux? ;-)

Other platforms such as GNU/Linux or Sun Solaris requires more code,
and there is this little "BSD versus GNU" ongoing preferences battle.
FreeBSD is on the same side as Darwin (Mac OS X) there, so to speak.

>> PS. You do want to bring this one over, though: (it's a bug)
>> http://trac.macports.org/projects/macports/ticket/12168
>> Without it, *everything* will link to Foundation framework.
>
> 	Landon made three commits that I've been reviewing this evening, the 
> one addressing this bug was the first. If FreeBSD support does go into 
> 1.5 this one will certainly be included.

My point here was this this particular bug doesn't have anything
to do with FreeBSD or GNUstep, it goes for Mac OS X and Cocoa too.
(library frameworks like universal binaries are a Mac OS X thing)

--anders