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:
mypkg-1.2.3
mypkg-1.2.4
mypkg-scm
Where -scm is a live ebuild that's been package.masked. However, some
packages have several active branches, so you'd get:
mypkg-1.2.3
mypkg-1.2.4
mypkg-1-scm
mypkg-2.0.1
mypkg-scm
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
signature.asc
Description: PGP signature
