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 <[email protected]>wrote: > [Changing the topic from build systems and replying just to the > original question] > > 2009/3/22 Darren Weber <[email protected]>: > > > > 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 mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
