On Thu, 26 Feb 2009 21:40:26 +0100 Luca Barbato <lu_z...@gentoo.org> wrote: > >> Be specific. Explain how this works when, say, 0.34.4 is current, > >> you have a 0.34.5_live and 0.34.5 comes out. > > being live working as substitute for 0.34.5_preN (_live) component > the appearance of 0.34.5 will be higher than those. If we consider > the .live alternative you'd have 0.34.live that is shadowed only by > 0.35.x
So it doesn't work Right. > That is pretty much the same you get with -scm, what happens is that > in the case of live template you have portage installing 0.34.5_preN > with revision informations and adding the template to the "live" set. No, with -scm the order works correctly. > >> How do I track an upstream who has a 0.34 branch (which is equal > >> to or ahead of the most recent 0.34.x release), a 0.36 branch > >> (which is equal to or ahead of the most recent 0.36.x release) and > >> a master branch (which is ahead of any release) using the live > >> property? > > the live property doesn't tell much about versioning > so you could use 9999 as the "x" version component or .live or -scm, > the live property just makes portage aware that the sources are live. > > This situation is one in those pkg-scm and pkg.live work better, but > just for one branch. > > As you said you could address the problem using useflags, so you > could by extension you can use the same way to address the single > case in proposals not supporting the tip of a single non version > branch as well: > > have the all the ebuilds in a package having IUSE=-live that if > enabled triggers the live property and changes the src_uri to the > live branch you desire. So if you do that, how does the package manager know that one version is less than another if a particular use flag is enabled, but greater than it if it is disabled? > Again it had been answered in the summary anyway. I thought you had a better answer than "it doesn't work" that I was just missing. Evidently not... -- Ciaran McCreesh
signature.asc
Description: PGP signature
