stable vs. unstable ports?

[Darren Weber]

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
<shreevatsa.public at gmail.com>wrote:

> [Changing the topic from build systems and replying just to the
> original question]
>
> 2009/3/22 Darren Weber <dweber at macports.org>:
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090326/58843e23/attachment.html>