Re: [31193] branches/release_1_6/base/src
On Nov 17, 2007, at 23:09, jmpp@macports.org wrote:
Revision: 31193 http://trac.macosforge.org/projects/macports/changeset/31193 Author: jmpp@macports.org Date: 2007-11-17 21:09:01 -0800 (Sat, 17 Nov 2007)
Log Message: -----------
Temporarily revert Landon's hiding of the Tcl cd command until remaining Portfiles are cleaned up. Currently there are still almost 300 ports that use the command and breaking them all in one fell swoop is not something we want to do!
Thanks. That's a relief. I'm working on a new script to give us a better indicator of how many ports are affected (and to show where). My complicated grep was inaccurate, markd pointed out, in that it gave false positives for (several) portfiles which used "cd" inside of ui_msg blocks, as instructions to the user, which should not be flagged as a problem.
One thing we should do is find a way to issue a suitable warning when Tcl's cd is called from a Portfile but not from port1.0, as that would be useless information.
An excellent idea. Much like we currently get notices about mtree violations.
On Nov 18, 2007, at 1:42 AM, Ryan Schmidt wrote:
On Nov 17, 2007, at 23:09, jmpp@macports.org wrote:
Revision: 31193 http://trac.macosforge.org/projects/macports/changeset/31193 Author: jmpp@macports.org Date: 2007-11-17 21:09:01 -0800 (Sat, 17 Nov 2007)
Log Message: -----------
Temporarily revert Landon's hiding of the Tcl cd command until remaining Portfiles are cleaned up. Currently there are still almost 300 ports that use the command and breaking them all in one fell swoop is not something we want to do!
Thanks. That's a relief.
I'm working on a new script to give us a better indicator of how many ports are affected (and to show where). My complicated grep was inaccurate, markd pointed out, in that it gave false positives for (several) portfiles which used "cd" inside of ui_msg blocks, as instructions to the user, which should not be flagged as a problem.
Thanks for this work Ryan! Please let us know when you have an accurate figure for the affected ports. And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
One thing we should do is find a way to issue a suitable warning when Tcl's cd is called from a Portfile but not from port1.0, as that would be useless information.
An excellent idea. Much like we currently get notices about mtree violations.
Thanks for the suggestion, I'll look into it. Regards,... -jmpp
On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote:
On Nov 18, 2007, at 1:42 AM, Ryan Schmidt wrote:
On Nov 17, 2007, at 23:09, jmpp@macports.org wrote:
Revision: 31193 http://trac.macosforge.org/projects/macports/changeset/ 31193 Author: jmpp@macports.org Date: 2007-11-17 21:09:01 -0800 (Sat, 17 Nov 2007)
Log Message: -----------
Temporarily revert Landon's hiding of the Tcl cd command until remaining Portfiles are cleaned up. Currently there are still almost 300 ports that use the command and breaking them all in one fell swoop is not something we want to do!
Thanks. That's a relief.
I'm working on a new script to give us a better indicator of how many ports are affected (and to show where). My complicated grep was inaccurate, markd pointed out, in that it gave false positives for (several) portfiles which used "cd" inside of ui_msg blocks, as instructions to the user, which should not be flagged as a problem.
Thanks for this work Ryan! Please let us know when you have an accurate figure for the affected ports.
My current count of portfiles that need to be fixed is 275, of which 123 are nomaintainer and 29 are openmaintainer. My new script and instructions for using it to see which ports are affected and where is in this ticket: http://trac.macports.org/projects/macports/ticket/12914 Here are the maintainers who my script currently thinks need to fix their ports (I'm not sending them an email just yet): a_rankine@yahoo.co.uk (1) anant@kix.in (1) anil@recoil.org (1) ari@ish.com.au (1) arsptr@swiftdsl.com.au (1) ascarter@gmail.com (1) aschenke@tampabay.rr.com (2) bacon@smithers.neuro.mcw.edu (1) bfulgham@mac.com (2) bfulgham@macports.org (1) bk532@iname.com (1) blair@macports.org (6) blb@macports.org (1) boeyms@macports.org (1) cbellot@sky.fr (1) cremes@mac.com (1) cshbell@gmail.com (1) darren.bane@gmail.com (1) dave@glowacki.org (2) davidm@astro.berkeley.edu (1) dem5302@cs.rit.edu (1) digdog@macports.org (1) dluke@geeklair.net (1) dreamind@dreamind.de (1) ecronin@gizmolabs.org (2) emmett.shear@gmail.com (1) emory.smith@gmail.com (3) erickt@macports.org (2) evenson@panix.com (2) fenner@research.att.com (1) glasser@mit.edu (1) gwright@macports.org (16) jberry@macports.org (1) jc@crazic.ru (1) jdputsch@comcast.net (1) jmpp@macports.org (8) jochen@macports.org (2) jwa@macports.org (3) kayos@genetikayos.com (1) landonf@macports.org (1) liontooth@cogweb.net (1) lomion@mac.com (2) markd@macports.org (2) mat@phpconsulting.com (1) me@thomaskeller.biz (3) mgrimes@macports.org (1) mwdiers@gmail.com (1) mww@macports.org (9) nomaintainer@macports.org (123) noses@noses.com (2) nox@macports.org (3) opendarwin.org@darkart.com (4) openmaintainer@macports.org (29) pelopor@nifty.com (1) pguyot@kallisys.net (7) pjenvey@groovie.org (1) pkern@debian.org (1) pmoura@logtalk.org (1) pmoura@mac.com (1) pmq@macports.org (1) prahl@bme.ogi.edu (1) reilles@loria.fr (1) ricci@macports.org (11) roederja@student.ethz.ch (2) sanchom@gmail.com (1) sbranzo@gmail.com (1) sfiera@macports.org (1) shadow@dementia.org (3) stechert@macports.org (2) tristan@cs.dartmouth.edu (1) vincent-opdarw@vinc17.org (2) vivek@khera.org (1) waqar@macports.org (11)
On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote:
And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
Apparently the lack of readline is making interactive mode very strange. Note how the prompt doesn't appear until after the thing I typed. $ port MacPorts 1.600 Entering interactive mode... ("help" for help, "quit" to quit) info sed Error: Port sed not found info gsed [macports/base] > [macports/base] > gsed 4.1.5, Revision 1, textproc/ gsed (Variants: universal, nls, with_default_names) http://www.gnu.org/software/sed/ Sed (streams editor) isn't really a true text editor or text processor. Instead, it is used to filter text, i.e., it takes text input and performs some operation (or set of operations) on it and outputs the modified text. Sed is typically used for extracting part of a file using pattern matching or substituting multiple occurances of a string within a file. Platforms: darwin Maintainers: nox@macports.org exit [macports/base] > Goodbye $ For comparison, here's the same exchange with 1.6.0-rc1: $ port MacPorts 1.600 Entering interactive mode... ("help" for help, "quit" to quit) [macports/base] > info sed Error: Port sed not found [macports/base] > info gsed gsed 4.1.5, Revision 1, textproc/gsed (Variants: universal, nls, with_default_names) http://www.gnu.org/software/sed/ Sed (streams editor) isn't really a true text editor or text processor. Instead, it is used to filter text, i.e., it takes text input and performs some operation (or set of operations) on it and outputs the modified text. Sed is typically used for extracting part of a file using pattern matching or substituting multiple occurances of a string within a file. Platforms: darwin Maintainers: nox@macports.org [macports/base] > exit Goodbye $
Juan Manuel Palacios wrote:
And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
The HACKING file is still present, and the README file is still missing... ? Not sure if you wanted http://trac.macports.org/projects/macports/ticket/13141 to be in 1.6, or just http://trac.macports.org/projects/macports/ticket/12779 Checking Xcode version, http://trac.macports.org/projects/macports/ticket/12794, is present on compile time but there are no warnings for binaries or upgrades. Maybe look into http://trac.macports.org/projects/macports/ticket/8401 and reopen http://trac.macports.org/projects/macports/ticket/13145 as well (preflight stuff) 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) Will make a "MacPorts-1.6.0RC2.tar.b2" tarball for testing other platforms tonight. --anders
On Nov 18, 2007, at 5:23 AM, Ryan Schmidt wrote:
On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote:
And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
Apparently the lack of readline is making interactive mode very strange. Note how the prompt doesn't appear until after the thing I typed.
---snip--- Yeah, quite annoying, the prompt appears only with output and then vanishes again when waiting for input. James is surely the best fit to comment on this, but in a rather Pontius-Pilate-way I guess we could say that it is highly recommended to enable readline support if you plan to use interactive mode. Nevertheless, I do agree this strange behavior is something that should be looked into. -jmpp
On 18/11/07 02:57, Ryan Schmidt wrote:
Here are the maintainers who my script currently thinks need to fix their ports (I'm not sending them an email just yet): sbranzo@gmail.com (1)
Sorry, here's the patch for the abook port https://svn.macosforge.org/projects/macports/ticket/13338 Gufo
On Nov 18, 2007, at 6:47 AM, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
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. 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?
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.
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).
Checking Xcode version, http://trac.macports.org/projects/macports/ticket/12794 , is present on compile time but there are no warnings for binaries or upgrades.
I like this idea and made some comments on the ticket just now. Is it something we can expect for 1.6.0? (regarding maturity of the idea and time to implement it)
Maybe look into http://trac.macports.org/projects/macports/ticket/ 8401 and reopen
Doable. Made a comment on the ticket, feedback would be great.
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. But as I said, I'm not happy about the state of things so I'll try again looking into it, but I wont make any promises.
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!
Will make a "MacPorts-1.6.0RC2.tar.b2" tarball for testing other platforms tonight.
Great! Let us know of status.
--anders
Regards,... -jmpp
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 ?
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
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.
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.
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"...
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 ? --anders
Juan Manuel Palacios wrote:
Will make a "MacPorts-1.6.0RC2.tar.b2" tarball for testing other platforms tonight.
Great! Let us know of status.
Source code tarball, and BSD / GNU binary packages posted at: http://trac.macports.org/projects/macports/browser/users/afb/RC/ Built and tested (ehum) with FreeBSD CURRENT and Fedora Rawhide. i.e. as in http://www.freebsd.org and http://fedoraproject.org/ Package build scripts are in portmgr/freebsd and portmgr/fedora, respectively. (one for the Ports collection, one for Yum repos) On the TODO list is how to install the basic system (OS + MP), and what requirements are needed beyond the basic GCC and X11... "platforms darwin freebsd linux" --anders
Hi Juan, On Nov 18, 2007, at 10:35 AM, Juan Manuel Palacios wrote:
On Nov 18, 2007, at 5:23 AM, Ryan Schmidt wrote:
On Nov 18, 2007, at 00:20, Juan Manuel Palacios wrote:
And while we're at it, I just created an rc2 tag for 1.6.0, differing from rc1 only in James' turning readline support into an optional configuration (r31139-31139 and merged into the release_1_6 branch in r31190) and in the Tcl cd command hiding reversion thing (r31193 only in the release_1_6 branch). Every developer/committer should reinstall MacPorts off this tag and test as extensively as possible!
Apparently the lack of readline is making interactive mode very strange. Note how the prompt doesn't appear until after the thing I typed.
We were missing a flush after the prompt was output, before the get operation. I added that single line in r31338:31339. Hope that can get into 1.6. James
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#R...
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
On Nov 20, 2007, at 11:50 AM, James Berry wrote:
Hi Juan,
We were missing a flush after the prompt was output, before the get operation. I added that single line in r31338:31339.
Hope that can get into 1.6.
Sure it will! I'll only wait a bit more in case there's something more to merge to do it all at once. -jmpp
Juan Manuel Palacios wrote:
Nah, myself I just thought the available pkg information should be better.
I'm sorry, I didn't follow that comment. Mind elaborating?
As long as the download links explains which version of DMG / PKG to get for which version of Mac OS X, most users will able to pick the right one.
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....? ;-)
The flat meta-packages seem to be broken with Xcode 3.0.0, so I wouldn't worry about it. Checking sw_vers in the script, probably works. I think there might be a built-in way to do it, but it's different for each OS. (i.e. one way for 10.3, one way for 10.4, one way for 10.5 - as usual...)
OK, will definitely try to fix it for that scenario. However, my recommendation still stands: avoid paths with spaces in them if possible!
No argument there... Goes for you too, Apple! "Application Support", sheesh.
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.
In order for the packages to be more useful, everything should be using them. So that you can mix and match binary packages and source packages freely... Like how Fink does it ? When you install a "port", it first builds a package and then installs the package. Thus, it knows about all the other "ports" too. In MacPorts, each package system (PKG/RPM/DEB) is separated from port registry. You can still do binaries, of course, just that it seems more likely that they would just be archives of destroot (tgz/tbz/tlz) instead of "real" packages ? The important things to me are a) installing ports *without* Developer Tools and b) remote download of pre-built binary packages and all their dependencies http://trac.macports.org/projects/macports/ticket/8571 (also involves fixing "upgrade" so it actually works) --anders PS. On an unrelated note, MacPorts 1.6.0RC2 installed OK on the Darwin 8.0.1 OS once the bogus dependencies on Foundation were hacked out (configure/tclobjc1.0) On the other two platforms I installed GNUstep instead, but there was no easy way of doing that on Darwin (but I guess I could have used DarwinPorts to bootstrap)
On Nov 21, 2007, at 00:29, Juan Manuel Palacios wrote:
On Nov 20, 2007, at 4:02 AM, Anders F Björklund wrote:
Juan Manuel Palacios wrote:
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!
Right. I don't see why it would matter where in the path (volume name, not volume name) spaces occur; spaces anywhere in the path are not going to be acceptable to a whole lot of build scripts. I once submitted a bug against a popular package asking them to support spaces in paths, and it was closed as wontfix. MacPorts itself should be made to fail (with an intelligible message) if installed to a prefix with a space anywhere in it, to avert any such problems that users would inevitably run into later.
participants (5)
-
Anders F Björklund
-
James Berry
-
Juan Manuel Palacios
-
Ryan Schmidt
-
Sbranzo