1.6.0 rc2 created (Was Re: [31193]
branches/release_1_6/base/src)
Juan Manuel Palacios
jmpp at macports.org
Tue Nov 20 22:29:03 PST 2007
On Nov 20, 2007, at 4:02 AM, Anders F Björklund wrote:
> Juan Manuel Palacios wrote:
>
>>> The HACKING file is still present, and the README file is still
>>> missing... ?
>> All our documentation will definitely be moved to the guide,
>> including the usual INSTALL, README, HACKING and similar text files
>> found in open source projects. We already have some of these and we
>> lack others, some are already in the guide and some still in our
>> sources, but they will all eventually end up there, as our
>> documentation authors manage to get to each of them.
>
> So does that means that it is now hands-off for everyone else, like
> with the manual pages ?
No, not at all! The contents of all our documentation will eventually
be "sorta" hands off rather than *completely* hands off because we
want to keep a limited set of eyes and hands working on it, so that
the overall result is more coherent than if just anyone who happens to
walk by tosses his/her bit of information in it, which leads to
disorganization and unreadability.
But that by no means implies that others can't contribute, make
suggestions, submit patches, discuss with Mark || Simon || Maun Suang,
etc. Everyone should feel free to do so, please! Our guide and man
pages are in this "sorta hands off state" 'cause they are already in
hands of our writers, but docs like README, HACKING and others aren't
yet, so feel free to claim it your own if you intend to ;-)
As stated previously, we do intend for all those to eventually end up
in the guide and therefore in this "sorta hands off" mode, but that's
still in the future.
>
>
>> Nevertheless, I say we keep the usual suspects in our sources but
>> only as placeholders pointing readers to the relevant sections in
>> the guide. What do you suggest we put in a README file?
>
> Just a dozen lines or so describing what it is, where it is, what it
> does and who did it.
> Like in http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/distpractice.html#README
I know what the file is about... I was wondering if you had a draft
for it ;-) Not a terrible thing if you don't, though, wont stop 1.6 ;-)
>
>
>>> Not sure if you wanted http://trac.macports.org/projects/macports/ticket/13141
>>> to be in 1.6,
>>
>> That would be sweet! Do you have any ETC/deliverables? I added a
>> small comment to the ticket which might be of help.
>
> Nah, myself I just thought the available pkg information should be
> better.
I'm sorry, I didn't follow that comment. Mind elaborating?
In any case, can you please take a look at what Ryan Maun Suang and I
discussed on that ticket? A *.pkg/Contents/Resources/VolumeCheck
script parsing the output of sw_vers(1) might do the trick for us, but
you've been working on the pkg targets lately so you're probably much
more fit than any of us to tell how we could achieve our goal on Tiger/
Leopard with traditional/flat pkg formats. Pretty please....? ;-)
>
>>> or just http://trac.macports.org/projects/macports/ticket/12779
>>
>> This relating only to the guide, it would be great to have it for
>> the time we release 1.6.0 too, but I don't think we need to tie
>> ourselves to it; it can happen at any moment (the guide is
>> regenerated nightly).
>
> Guide and Website, it was. As in: wherever the Download link is
> presented.
Ack! Will advise Mark on that one when he's available again.
>
>
>>> http://trac.macports.org/projects/macports/ticket/13145 as well
>>> (preflight stuff)
>>
>> Though I'm not incredibly happy with the state of this issue, it
>> is a matter of fact that dealing with paths containing spaces can
>> turn into a major headache for us (and I'm not just referring to
>> MacPorts itself here, I can't imagine the thousands of ports that
>> we distribute that might hide this type of bugs in their
>> configurations and/or Makefiles.... uuughhh!). I tried
>> bootstrapping MacPorts into a path with spaces and couldn't even
>> get through our own configuration script, let alone get to my dp2mp-
>> move upgrading rules to try to bullet-proof them. I know the
>> original poster's problems creeps up when I try to upgrade his
>> personal configuration file, as it's the path to his home dir what
>> contains spaces and not MacPorts' prefix, but it's basically the
>> same situation.
>
> I'm not suggesting that paths with spaces should be supported. I
> just wanted *volumes* with spaces in their names to be supported,
> while still installing in the usual /opt/local prefix locally on the
> volume... The original poster mentioned that a manual install works
> just fine, it's just the preflight script in the package that is
> referring to things with "/Volumes/Litter Box" prefixed to the
> regular paths ? I know someone else wanted to install in their home
> folder, while it was located on a path with spaces, but that is an
> issue "for later"...
OK, will definitely try to fix it for that scenario. However, my
recommendation still stands: avoid paths with spaces in them if
possible!
>
>
>>> I probably won't be updating MP 1.6 to RPM 4.5 and Python 2.5 for
>>> the rpm packaging
>>> targets/ports, as I had originally intended. (It'll still use RPM
>>> 4.4 / Python 2.4)
>>
>> Not a problem, whenever you're ready!
>
> Since RPM 4.5 has not been released yet and since not all of the
> other ports work with Python 2.5 yet, it won't be a priority this
> year. Besides, RPM 5.0 is where the development happens - and it is
> currently in alpha testing.
> The only major casualty of sticking with 4.4/2.4 is the Smart GUI,
> since it needs GTK+ and the "py-gtk2" port isn't available anymore.
> Then again the Smart text interface is still working OK, once
> python24 is made to limp along.
>
> The current RPM ports should be more than enough to sort out the
> other problems that MacPorts has with binary package (rpm) building
> - at the moment it looks like doing binary archives (tlz) would be a
> better alternative ?
First comes building logging support into MacPorts (my nex goal & top
priority after the new website and 1.6) and then constructing our
automated & distributed builds infrastructure (build farms, chroots,
trace mode, etc) to actually have something to package, so I wouldn't
worry too much just yet about fleshing out rpm issues in MacPorts at
the moment. I more than love the effort and work you're putting into
packaging and how you're pushing us forward on this front, trust me
(!!); but, sadly, whatever packaging effort we put together is going
to be pretty lousy without support for automated builds & logging.
>
>
> --anders
>
Regards,...
-jmpp
More information about the macports-dev
mailing list