For MacPorts 1.6.0, I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO. It also needs a cooler name... Such as "Evolution", as in: I'm running the latest MacPorts Evolution. :-) --anders
Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
I second that. Or perhaps a bit a more elaborate scheme like fink uses it: namely a stable and an unstable tree. Would make things much more reliable.
It also needs a cooler name... Such as "Evolution", as in: I'm running the latest MacPorts Evolution. :-)
If people want fancy names...
--anders
Michael
On Oct 2, 2007, at 05:05, Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
Specifically, what?
Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
That sounds like a good idea. But who decides at which time we merge revisions from unstable to stable? And do we have enough resources (I mean: contributors and testers) to find all problems? Would this really help to find problems at all? A good reason is, we could adopt new features from base in unstable first and merge them to stable once a new base gets released. For example, removing of "cd" from all ports. Or introduction of compiler.*. But for this we need some place to track those changes and mark them for a later merge. Where should we store which revisions are to be merged to stable? And who will do the merging? It sounds great, but are we ready to manage more than one ports tree? Rainer
On 3 Oct 2007, at 05:37, Rainer Müller wrote:
Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
That sounds like a good idea. But who decides at which time we merge revisions from unstable to stable? And do we have enough resources (I mean: contributors and testers) to find all problems? Would this really help to find problems at all?
If we had a build farm, the farm could catch every build error, so that the only ports in the "stable" tree would have runtime errors.
A good reason is, we could adopt new features from base in unstable first and merge them to stable once a new base gets released. For example, removing of "cd" from all ports. Or introduction of compiler.*.
But for this we need some place to track those changes and mark them for a later merge. Where should we store which revisions are to be merged to stable? And who will do the merging?
It sounds great, but are we ready to manage more than one ports tree?
If we could automate it?
Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Le 2 oct. 07 à 13:05, Michael Wild a écrit :
Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
I second that.
Or perhaps a bit a more elaborate scheme like fink uses it: namely a stable and an unstable tree.
Would make things much more reliable.
I would rather see this problem resolved by working on a major modification against base/ code: multiple versions for each port. Only one tree would be required, and we could use a fine-grained dependency system as it is in Gentoo Portage.
It also needs a cooler name... Such as "Evolution", as in: I'm running the latest MacPorts Evolution. :-)
If people want fancy names...
--anders
Michael
-- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Oct 2, 2007, at 16:16, N_Ox wrote:
Le 2 oct. 07 à 13:05, Michael Wild a écrit :
Anders F Björklund wrote:
For MacPorts 1.6.0,
I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO.
I second that.
Or perhaps a bit a more elaborate scheme like fink uses it: namely a stable and an unstable tree.
Would make things much more reliable.
I would rather see this problem resolved by working on a major modification against base/ code: multiple versions for each port.
Only one tree would be required, and we could use a fine-grained dependency system as it is in Gentoo Portage.
For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that?
Ryan Schmidt wrote:
For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that?
One could choose which version to install without loosing dependencies. For example, all of our *-devel ports are useless because they break the depedencies. For example, you can't install something like apache2-devel and add php5, because php5 depends on the normal apache2. With multiple version per port this would be possible. But it would also require the introduction of new commands that allow a port to depend on at least a specific version of another port. We could mark the different versions as "stable" or "unstable". With this approach we would get a better environment to test port upgrades with beta versions or release candidates. Rainer
Citando Rainer Müller :
Ryan Schmidt wrote:
For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that?
One could choose which version to install without loosing dependencies. For example, all of our *-devel ports are useless because they break the depedencies. For example, you can't install something like apache2-devel and add php5, because php5 depends on the normal apache2.
With multiple version per port this would be possible. But it would also require the introduction of new commands that allow a port to depend on at least a specific version of another port.
We could mark the different versions as "stable" or "unstable". With this approach we would get a better environment to test port upgrades with beta versions or release candidates.
Being a simple maintainer, I would say that dependencies on specific version (à la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports. The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports. It can at the moment be achieved through the old dependency scheme (sthg like depends_lib bin:mpd:mpd-devel) but that scheme cannot discriminate between something provided by macports and something provided by apple or another source. Emmanuel
Le 4 oct. 07 à 22:32, Emmanuel Hainry a écrit :
Citando Rainer Müller :
Ryan Schmidt wrote:
For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that?
One could choose which version to install without loosing dependencies. For example, all of our *-devel ports are useless because they break the depedencies. For example, you can't install something like apache2-devel and add php5, because php5 depends on the normal apache2.
With multiple version per port this would be possible. But it would also require the introduction of new commands that allow a port to depend on at least a specific version of another port.
We could mark the different versions as "stable" or "unstable". With this approach we would get a better environment to test port upgrades with beta versions or release candidates.
Being a simple maintainer, I would say that dependencies on specific version (à la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports.
How would that make you unable to maintain your ports? I don't understand your point.
The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports. It can at the moment be achieved through the old dependency scheme (sthg like depends_lib bin:mpd:mpd-devel) but that scheme cannot discriminate between something provided by macports and something provided by apple or another source.
Emmanuel
We can use path:${prefix}/bin/mpd:mpd, but how manage things like postgresql8*? For example, how could you easily set dependencies for packages such as phpmyadmin and phppgadmin? You can't. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
Emmanuel Hainry wrote:
Being a simple maintainer, I would say that dependencies on specific version (à la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports.
Why? I just don't get this point.
The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports.
Okay, let's call it "metaport". But it is the same thing you are describing. A port which provides multiple versions of a software. Nevertheless, dependencies have to go in each version of a port. A development snapshot could have completely different dependencies than the current "stable" version. Rainer
Citando Rainer Müller :
Emmanuel Hainry wrote:
Being a simple maintainer, I would say that dependencies on specific version (à la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports.
Why? I just don't get this point.
I know the ports I maintain build with the latest versions of their dependencies at the time I uploaded the Portfile. I am unable to predict breakage (for example when libogg changed its API, mpd did not build anymore) and I am even more unable to decide if it builds against each version of each of its dependencies. The current way is tractable for me, adding such possibility would mean far more testing than trying to build the port with the differents combinations of variants. If the other maintainers have far more free time than I do, maybe it can work and the tree will not be full of untested dependencies. Seeing the number of unmaintained ports, and the numbers of tickets in trac (even simple updates), I would say that it is not the case.
The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports.
Okay, let's call it "metaport". But it is the same thing you are describing.
Yes, I just stated that it was the part of what you proposed I found interesting: as long as it is not taken too far.
A port which provides multiple versions of a software. Nevertheless, dependencies have to go in each version of a port. A development snapshot could have completely different dependencies than the current "stable" version.
Yes of course. The metaport metaphp would depend on php5 or php52 or any version. But those ports keep their current portfile. Then ports depending on "just any version of php" would put depends-lib metaphp in their portfile. Emmanuel
Ryan Schmidt wrote:
There is just too much port breakage with running the latest developer version on the user machines, IMHO.
Specifically, what?
It's usually fixed quickly, but surely errors happen ? I meant it like developer=unstable and release=stable. --anders
Rainer Müller wrote:
A good reason is, we could adopt new features from base in unstable first and merge them to stable once a new base gets released. For example, removing of "cd" from all ports. Or introduction of compiler.*.
This was what I was thinking about, yes. Or when upgrading one port, but "failing" to upgrade all of the dependencies in the first commit. Or just to get a little "quarantine" in order to test new releases and updated ports, before introducing them on production machines ?
It sounds great, but are we ready to manage more than one ports tree?
Probably not, as there isn't enough resources maintaining even one tree. I just think it would be a good idea, even if it moved really really slow. One could start out with a copy of the "archive", and then merge ports one by one from the "trunk" - either manually or maybe just by timer... --anders
participants (7)
-
Anders F Björklund
-
Emmanuel Hainry
-
Michael Wild
-
N_Ox
-
Rainer Müller
-
Randall Wood
-
Ryan Schmidt