Re: Activation error
Hello, The -f took care of the problem. Thank you. Frank On Mar 26, 2009, at 4:58 PM, Joshua Root wrote: William Davis wrote: Usually that is a left over file from a failed install. In this case just do sudo port -f upgrade xorg-libX11 [or do -fu if you don't want to keep the old version] Don't do that. Upgrade normally applies to all dependencies as well, so you would be rebuilding all of them because of the -f. (You can use -n to avoid processing dependencies.) In fact, -f upgrade is not called for in this situation at all, but rather -f activate. - Josh Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
On Mar 26, 2009, at 17:51, Darren Weber wrote: On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell wrote: On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote: Before we can allow arbitrary users to submit their builds to a central server, we would need to ensure that a build that occurs on one user's system is *identical* to the build on any other user's computer. This cannot currently be assured because MacPorts does not build in a chroot, and without this, it is possible for a port to link with libraries that happen to be on the user's system that it ought not link with -- be they libraries from other ports on which the port in question does not declare a dependency, or libraries in /usr/local, to which the compiler always looks. Would two "identical builds" be byte-identical? If so, then a binary doesn't become available until *two* (or three or whatever) identical binaries are uploaded. And/or, there's some command line library tool (I'm on vacation and my reference books are home) that I can run to get a listing of what libraries are called by a particular binary, isn't there? Wouldn't that help screen wacky-linked binaries? The deliberate uploading of contaminated binaries, however, is a whole different kettle of worms. :/ I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the "official" and "secure" port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Libraries and compressed files (which include manpages) tend to differ everytime they're built, even if they're functionally the same. So you can't just run an md5 checksum over everything and expect it to be the same after repeated builds. I hadn't thought of securing a distributed build system from malicious users until Joshua's message, but now I agree that from a security standpoint we cannot allow user-uploaded binaries at all. Dave's proposed safeguard of requiring n users to upload functionally identical files isn't going to help; if a malicious user can upload a bad binary from 1 computer, they can borrow n friends' computers and create n throwaway email addresses and upload the binary how ever many times we've specified. There are botnets out there with thousands of computers that can be commandeered by hackers to do whatever. So let's kill the idea of user-submitted binaries now. We want dedicated build servers under the control of the MacPorts project. So let's flesh out MPAB into something that can be run on such build servers. Then we can look at acquiring the servers. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: php5 & "port test php5"
On Mar 23, 2009, at 15:00, drf wrote: My setup: Mac Mini, 10.4.11, Xcode 2.5, GCC 4, MacPorts 1.7 Everything compiles fine, there are some complaints about signedness from the compiler, but it all looks ok. But when I run the PHP test suite, over 70 tests fail, including ones I wouldn't really expect, like on the function easterdate(). I can not find any hints anywhere on what might be happening, so I'm wondering if these tests really are that important. Should a completely default, standard, stock install of php5 with MacPorts pass all the PHP self tests fine? The thing is, when I set up everything myself (not using MacPorts to compile php5) the same set of tests failed - the config of php5 did reference various macport installed libraries, etc. I am now at the point where I am wondering if I ought to toss all of MacPorts and try to install everything myself that is needed to compile php5. So any advice, pointers on where to look, or hints on 64 bit vs 32 would be greatly appreciated Hi. I'm the maintainer of php5 in MacPorts. On the few occasions when I have tried "port test php5", it did not pass everything either. Please feel free to enter into a dialog about this with the developers of PHP. I have not had the energy to do so myself. They're often quite rude in responding to bug reports and I haven't felt like being abused lately. I recommend you use MacPorts for all your software installation needs, including PHP. You could build it all yourself, but it would be a lot of work figuring out things that we have already figured out in MacPorts. If the software available in MacPorts doesn't fully meet your needs, please bring it to our attention so that we can improve the ports until they do meet your needs. I have not attempted to compile php5 as a universal binary or 64-bit. I would not be surprised if it did not work. If you try it and it works, or if you can figure out how to make it work, please let us know. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: dbus startup at system startup.
On Mar 24, 2009, at 14:22, Frank J. R. Hanstick wrote: On Mar 24, 2009, at 8:50 AM, Frank J. R. Hanstick wrote: At system startup, I get the following error messages sent to system.log: Mar 24 08:40:11 localhost launchd: org.macports.dbus: respawning too quickly! throttling Mar 24 08:40:11 localhost launchd: org.macports.dbus: 9 more failures without living at least 60 seconds will cause job removal Mar 24 08:40:11 localhost launchd: org.macports.dbus: will restart in 10 seconds [snip] I installed dbus via sudo port install dbus and entered: launchctl load /Library/LaunchAgents/org.freedesktop.dbus- session.plist as directed; yet, I still get these error messages at system startup time. How do I get them to stop? I figured out the problem. Somehow, the plist associated with org.macports got inserted into LaunchDaemons. I removed it and the dbus messages stopped appearing. Great when I can solve my own problems once in a while. The dbus port is supposed to install the file org.macports.dbus.plist into /Library/LaunchDaemons, and the file org.freedesktop.dbus- session.plist into /Library/LaunchAgents. At least, it does so on my system. I have never attempted to start them though. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Activation error
right you are! WSD On Mar 26, 2009, at 7:58 PM, Joshua Root wrote: William Davis wrote: Usually that is a left over file from a failed install. In this case just do sudo port -f upgrade xorg-libX11 [or do -fu if you don't want to keep the old version] Don't do that. Upgrade normally applies to all dependencies as well, so you would be rebuilding all of them because of the -f. (You can use -n to avoid processing dependencies.) In fact, -f upgrade is not called for in this situation at all, but rather -f activate. - Josh William Davis frstanATbellsouthDOTnet Mac OS X.5.6 Darwin 9.5.0 XQuartz 2.3.3_rc2 (xorg-server 1.4.2-apple37) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Google Summer of Code 2009 - Money for students working on MacPorts!
Hi, Summer of Code is a annual program hold by Google to attract new developers for the open source world. You work on a open source project over the summer and earn $4500 USD. It is a great opportunity for college students to get a real, on the ground programming experience, work on an exciting open source project with mentoring from its developers. MacPorts has great tasks on the ideas page that could use attention, and still has slots for volunteers. Get in contact with us and apply if you are interested! Please also spread the word if you are a MacPorts user and a friend of yours would be qualified. This is a great opportunity not just for the students, but to foster and extend the MacPorts project. See this wiki page for more information: http://trac.macports.org/wiki/SummerOfCode Application is still open until April 3, 19:00 UTC. For more details, just contact the list, me or any of the mentors. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Activation error
William Davis wrote: > Usually that is a left over file from a failed install. In this case just do > sudo port -f upgrade xorg-libX11 [or do -fu if you don't want to keep > the old version] Don't do that. Upgrade normally applies to all dependencies as well, so you would be rebuilding all of them because of the -f. (You can use -n to avoid processing dependencies.) In fact, -f upgrade is not called for in this situation at all, but rather -f activate. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Activation error
Usually that is a left over file from a failed install. In this case just do sudo port -f upgrade xorg-libX11 [or do -fu if you don't want to keep the old version] WSD On Mar 26, 2009, at 6:46 PM, Frank J. R. Hanstick wrote: Hello, I got the following activation error: ---> Activating xorg-libX11 @1.2_0 Error: Activating xorg-libX11 @1.2_0 failed: Image error: /opt/local/ include/X11/cursorfont.h already exists and does not belong to a registered port. Unable to activate port xorg-libX11. when trying the following command: sudo port upgrade xorg-libX11 Any ideas anyone? Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users William Davis frstanATbellsouthDOTnet Mac OS X.5.6 Darwin 9.5.0 XQuartz 2.3.3_rc2 (xorg-server 1.4.2-apple37) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Install from Binary Archives (was Re: port install efficiency issue)
On Thu, Mar 26, 2009 at 3:19 PM, Rainer Müller wrote: > Dave Howell wrote: > > What about this: I do a "ports install widget", ports looks for a > > binary, doesn't find one that matches (in this case, the default > > options and current version), so it goes about building it. When it's > > done, it says "upload compiled binary to binary archives?" I say "Y", > > and up it goes. Now it's available for the next user who comes along. > > Sure, we would just distribute arbitrary binaries to end-users... NOT! > Ever thought about security? What if I upload some rootkit instead of > the real software and everyone installs it? No, this will not work. > > Rainer > I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the "official" and "secure" port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Best, Darren PS, `man otool` can tell you just about anything you need to know about the binary file, eg otool -l /opt/local/bin/gls otool -L /opt/local/bin/gls ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell wrote: > > On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote: > > >> Before we can allow arbitrary users to submit their builds to a central >> server, we would need to ensure that a build that occurs on one user's >> system is *identical* to the build on any other user's computer. This cannot >> currently be assured because MacPorts does not build in a chroot, and >> without this, it is possible for a port to link with libraries that happen >> to be on the user's system that it ought not link with -- be they libraries >> from other ports on which the port in question does not declare a >> dependency, or libraries in /usr/local, to which the compiler always looks. >> > > Would two "identical builds" be byte-identical? If so, then a binary > doesn't become available until *two* (or three or whatever) identical > binaries are uploaded. > > And/or, there's some command line library tool (I'm on vacation and my > reference books are home) that I can run to get a listing of what libraries > are called by a particular binary, isn't there? Wouldn't that help screen > wacky-linked binaries? > > The deliberate uploading of contaminated binaries, however, is a whole > different kettle of worms. :/ > > I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the "official" and "secure" port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Best, Darren PS, `man otool` can tell you just about anything you need to know about the binary file, eg otool -l /opt/local/bin/gls otool -L /opt/local/bin/gls ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Activation error
Hello, I got the following activation error: ---> Activating xorg-libX11 @1.2_0 Error: Activating xorg-libX11 @1.2_0 failed: Image error: /opt/local/ include/X11/cursorfont.h already exists and does not belong to a registered port. Unable to activate port xorg-libX11. when trying the following command: sudo port upgrade xorg-libX11 Any ideas anyone? Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Install from Binary Archives (was Re: port install efficiency issue)
Dave Howell wrote: > What about this: I do a "ports install widget", ports looks for a > binary, doesn't find one that matches (in this case, the default > options and current version), so it goes about building it. When it's > done, it says "upload compiled binary to binary archives?" I say "Y", > and up it goes. Now it's available for the next user who comes along. Sure, we would just distribute arbitrary binaries to end-users... NOT! Ever thought about security? What if I upload some rootkit instead of the real software and everyone installs it? No, this will not work. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: re Gnucash crashes on launch
2009/3/26 Gregory Dodwell > Date: Wed, 25 Mar 2009 19:09:44 +0100 > From: Olaf Foellinger > Subject: Re: Gnucash crashes on launch: no, I don't have mesa > To: macports-users@lists.macosforge.org > Message-ID: <20090325180944.ga1...@foellinger.de> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > > * Gregory Dodwell [25.03.09 12:38]wrote: > > >>OSX 10.5.6 "Leopard" on Intel iMac > >>Xquartz 2.3.2 > >>Latest MacPorts: version 1.700 > >>trying to run after installation today: > >>Here's me: /opt/local/bin/gnucash-bin > >>In reply a partially drawn splash for a couple of seconds then: > >>gnc.bin-Message: main: binreloc relocation support was disabled at > >>configure time. > >> Xlib: extension "RANDR" missing on display "/tmp/launch-IUF4Zq/:0". > >> Abort trap > > > Any clues? > > > maybe you can try the script /opt/local/bin/gnucash? > > > > Gru? Olaf > > I tried that script, and also tried backgrounding it for good measure --no > luck-- here's the result: > There is a discussion about this being related to mesa. See: http://www.nabble.com/Symbol-not-found:-_gll_noop-td22241078.html > > bash-3.2$ /opt/local/bin/gnucash > dyld: Symbol not found: _gll_noop > Referenced from: > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > Expected in: /opt/local/lib/libGL.dylib > > Trace/BPT trap > bash-3.2$ /opt/local/bin/gnucash & > [1] 88155 > bash-3.2$ dyld: Symbol not found: _gll_noop > Referenced from: > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL > Expected in: /opt/local/lib/libGL.dylib > > > [1]+ Trace/BPT trap /opt/local/bin/gnucash > bash-3.2$ > > > > > > ___ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users > > ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
re Gnucash crashes on launch
Date: Wed, 25 Mar 2009 19:09:44 +0100 From: Olaf Foellinger Subject: Re: Gnucash crashes on launch: no, I don't have mesa To: macports-users@lists.macosforge.org Message-ID: <20090325180944.ga1...@foellinger.de> Content-Type: text/plain; charset=iso-8859-1 Hi, * Gregory Dodwell [25.03.09 12:38]wrote: >>OSX 10.5.6 "Leopard" on Intel iMac >>Xquartz 2.3.2 >>Latest MacPorts: version 1.700 >>trying to run after installation today: >>Here's me: /opt/local/bin/gnucash-bin >>In reply a partially drawn splash for a couple of seconds then: >>gnc.bin-Message: main: binreloc relocation support was disabled at >>configure time. >> Xlib: extension "RANDR" missing on display "/tmp/launch-IUF4Zq/:0". >> Abort trap > > Any clues? > maybe you can try the script /opt/local/bin/gnucash? > Gru? Olaf I tried that script, and also tried backgrounding it for good measure --no luck-- here's the result: bash-3.2$ /opt/local/bin/gnucash dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /opt/local/lib/libGL.dylib Trace/BPT trap bash-3.2$ /opt/local/bin/gnucash & [1] 88155 bash-3.2$ dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /opt/local/lib/libGL.dylib [1]+ Trace/BPT trap /opt/local/bin/gnucash bash-3.2$ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Cannot install protocols for pkill and pgrep
On Mar 26, 2009, at 16:00 , Doug Daniels wrote: I'm attempting to install the protocols library from port on Mac OS X 10.5.6. I see it listed on the macports website: http://trac.macports.org/browser/trunk/dports/sysutils/proctools/Portfile I updated my port: sudo port selfupdate Then I try to do a sudo port list | grep protocols and I don't see it listed at all. I run: / >sudo port install protocols Password: Error: Port protocols not found spelling error? proctools but you typed protocols Do I need to modify my sources.conf or something to get the Protocols library? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote: Before we can allow arbitrary users to submit their builds to a central server, we would need to ensure that a build that occurs on one user's system is *identical* to the build on any other user's computer. This cannot currently be assured because MacPorts does not build in a chroot, and without this, it is possible for a port to link with libraries that happen to be on the user's system that it ought not link with -- be they libraries from other ports on which the port in question does not declare a dependency, or libraries in / usr/local, to which the compiler always looks. Would two "identical builds" be byte-identical? If so, then a binary doesn't become available until *two* (or three or whatever) identical binaries are uploaded. And/or, there's some command line library tool (I'm on vacation and my reference books are home) that I can run to get a listing of what libraries are called by a particular binary, isn't there? Wouldn't that help screen wacky-linked binaries? The deliberate uploading of contaminated binaries, however, is a whole different kettle of worms. :/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Cannot install protocols for pkill and pgrep
I'm attempting to install the protocols library from port on Mac OS X 10.5.6. I see it listed on the macports website: http://trac.macports.org/browser/trunk/dports/sysutils/proctools/Portfile I updated my port: sudo port selfupdate Then I try to do a sudo port list | grep protocols and I don't see it listed at all. I run: / >sudo port install protocols Password: Error: Port protocols not found Do I need to modify my sources.conf or something to get the Protocols library? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Install from Binary Archives (was Re: port install efficiency issue)
On Mar 22, 2009, at 22:54 , Darren Weber wrote: I In effect, every time anybody on this grid has to build a package from source, some kind of meta-package monitor can detect whether the build and install was successful and then make an inquiry of a central managment system as to whether or not this build should be added to the mirrors for binary distributions. If this inquiry was made before the build and a binary is available somewhere, the system simply downloads the binary (perhaps a torrent system). If the binary is not available, the build proceeds. Maybe I'm not following it correctly, but it sounds very complicated. What about this: I do a "ports install widget", ports looks for a binary, doesn't find one that matches (in this case, the default options and current version), so it goes about building it. When it's done, it says "upload compiled binary to binary archives?" I say "Y", and up it goes. Now it's available for the next user who comes along. When I first install MacPorts, I could select at that time to en/ disable the "upload binaries" option. This scheme inherently selects for more popular configurations. If nobody ever happens to ask for a particular setup, it'll never take up space in the archive. There is probably some effort on somebody's part required to help figure out when a particular binary is actually a match or not. Widget 3.2 compiled on Intel 2.0GHz Core 2 Duo under OSX 10.5.2 with gcc 4.0 from XCode 3.0 Widget 3.2 compiled on Intel 2.0GHz Core 2 Duo under OSX 10.5.2 with gcc 4.0 from XCode 3.1.2 Widget 3.2 compiled on Intel 2.0GHz Core 2 Duo under OSX 10.5.4 with gcc 4.0 from XCode 3.1.2 Same or different? I personally don't think I know enough to be able to answer that question, but I know enough to believe that the answer is not necessarily the same for different ports, depending on what they link to? I certainly love the sound of "port install fuudingus" saying There is a binary for this port available. Compiled under OSX 10.5.4 with gcc 4.0 from XCode 3.1.2 Warning! Your installation of XCode is 3.0 Would you like to install from the binary file (Y/N)? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
Recently, I was running something like update-all and there were some issues
with the netCDF library. It was upgraded by the maintainer, who manually
updated a dependency on HDF5 within their dev environment, who then put out
a request to the HDF5 maintainer to update that package, but this could not
happen because of other dependencies on HDF5. This situation persisted for
quite some time. As a consequence, the netCDF package was broken during the
upgrade process. (Please forgive me if any or all of these recollections
are just plain wrong, but something like this happened and it's just the
main idea that's important).
Despite all the reasons why this might or might not be a good process model,
I don't like it for daily work. For the purpose of my daily work, I do want
a stable environment, I don't need to be on the cutting edge (or is that a
bleeding edge). There are times when I want to get closer to the cutting
edge - that's when I grab and modify the Portfile in my local repository and
tinker with it (and any dependency issues, etc.). I do like the way this is
possible in macports. However, for the vast majority of packages, I just
want them to work, I want them to be stable and I want them to be nice to
each other, to work in harmony.
I would love an automated tagging system that can monitor the success or
failure of port builds and trace this status through the dependency tree to
automatically identify the conjunction of all stable ports. It should
provide a report of that information to the maintainers of each package,
indicating the status of builds (broken down by variants and including a
relevant dependency list for each build-type that fails - not EVERY build,
just the category of build that fails). All this currently happens in trac
and it requires a lot of effort to monitor and manage it. Perhaps some of
that effort could be spent on programming a meta-port monitor and status
report system.
In effect, macports already has multiplicity of ports for each package,
mainly because there are separate ports for each major-minor release of a
package (like postgresql-83, etc.) and so do many other port or package
management systems. It's not uncommon for a large package management system
to deal with the contingencies of multiple versions for a package, including
installation of multiple versions at the same time (due to user preferences
or due to package dependency).
At some point, in some way, it is inevitable that a package management
system must have some kind of stable - unstable tag on it's packages
(ports), whether it is automatic or manual (ie, developer decisions). At
present, it appears this is all manual in macports and there is no way for a
user to use a simple category selector in the port program, but perhaps your
suggestion for python is a move toward some level of automation.
Thanks, Darren
On Tue, Mar 24, 2009 at 8:25 PM, Shreevatsa R
wrote:
> [Changing the topic from build systems and replying just to the
> original question]
>
> 2009/3/22 Darren Weber :
> >
> > I've noticed problems during port upgrades.
> >
> > What is the general consensus on having a TAG for each port to indicate
> it's
> > "success" status within the system?
>
> There is already a low-tech way of doing this: see if any bugs have
> been reported against the given port. :)
> Chances are that if others have had problems with upgrades, they would
> have (hopefully) filed a ticket against the port.
> Checking this is very easy to do thanks to Rainer Müller's recently
> implemented Trac report, e.g. use
> http://trac.macports.org/report/16?PORT=python25
> to see if there are any recent bugs with the python25 port that you care
> about.
>
> > Is it possible to have a meta-port monitor that automatically tracks the
> > status of each package install and reports that status back to a central
> > repository to continuously flag the status of a port install. A simple
> > dichotomy of stable and unstable might suffice (Debian uses stable,
> > unstable, and testing). Perhaps the monitoring system could provide the
> > data required to justify these port status levels.
>
> Note that what Debian does is something quite a bit more: they have
> entirely different *sets* of ports marked stable, testing, unstable
> and users choose to install all their packages from the same set
> ("tree"). This is fine for Debian to do because they have enough
> people, but it would not be a good idea for MacPorts: having to
> maintain multiple sets of inter-compatible ports leads to too much
> fragmentation and the situation might end up similar to that with
> Fink: the stable ports work very well but are too outdated for most
> purposes, the unstable ports are really unstable and *still* quite a
> bit older than in MacPorts. Having only one current version of each
> port, which everyone gets and reports bugs against etc. is one of
> MacPorts's strengths.
>
___
macports-users ma
Re: stable vs. unstable ports?
Darren Weber wrote: I've been working with macports under the mis-apprehension that it would operate along the lines of freeBSD (and some frustration may arise mostly from that lack of understanding). I decided that it's time for me to do some long-overdue homework. I've been working mostly with linux (and developed a preference for Debian-Ubuntu), so I need to get educated about BSD, as macports seems to follow that model (to some extent). Not only MacPorts, but also Mac OS X is closer to FreeBSD than to Linux. On the other hand, many of the tools in use (such as bash or make) are from GNU, so it's something of a mix between BSD and GNU... For the really adventurous, it's even possible to install MacPorts on FreeBSD and on GNU/Linux. There are packages available for FreeBSD, Fedora and Ubuntu. Not many ports, but "base" should still run. --anders ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
