On Mon, 10 Dec 2007 13:14:56 +0530
"Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote:
> On Dec 10, 2007 12:48 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > Feature as opposed to release branches would still have to be
> > separate packages, especially if you need to depend upon a
> > particular feature.
> I don't understand how having to depend on a particular feature causes
> one to need a separate package.

Because depending on a particular feature is a whole different kettle
of fish to having a sane alternative to -9999 or -cvs packages. 

> Why not just have something like
> sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?

Because it breaks deps. Simplest example: if I
block !=sys-devel/gcc-4.2.3* because of a bug (and gcc isn't an ideal
example here), I'm also blocking branches that don't have said bug.
When this is extended with long-lasting feature branches the situation
gets very very messy.

> Also, releases are often tagged rather than being branched out, which
> would have to be kept in mind as well.

No, for releases you follow the normal version mechanism.

Incidentally, I suspect the gcc example with _p is confusing people. The
normal use for an -scm suffix will be as follows:


Where -scm is a live ebuild that's been package.masked. However, some
packages have several active branches, so you'd get:


Where -1-scm is a live ebuild for branches/1/ and -scm is a live ebuild
for trunk/. In particular, observe how 1-scm is < 2.0.1.

The whole _p thing only comes up for those very rare (or possibly
non-existent) projects that have patchset branches that are themselves
live. I highly doubt that many people will make use of anything other
than -scm or -number(.number)-scm. There's no reason to shove an -scm
suffix onto a package made from a static tarball, and the -scm suffix
does not replace existing mechanisms for indicating snapshots.

Ciaran McCreesh

Attachment: signature.asc
Description: PGP signature

Reply via email to