FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-10-2007, 06:49 PM
"Nirbheek Chauhan"
 
Default scm package version suffix

On Dec 11, 2007 1:14 AM, Nirbheek Chauhan <nirbheek.chauhan@gmail.com> wrote:
> Of course this could be extended to apply only to branch ebuilds
> without a version number (where you know when the branch will be
> merged), etc.

s/you know/you don't know/

--
~Nirbheek Chauhan
--
gentoo-dev@gentoo.org mailing list
 
Old 12-10-2007, 11:27 PM
Steve Long
 
Default scm package version suffix

Nirbheek Chauhan wrote:

> On Dec 10, 2007 8:44 PM, Robert Buchholz <rbu@gentoo.org> wrote:
>> That would still mean everything relies on n ebuilds with mutual blocks.
>> Even if that would work and it block upgrades, it is still not a
>> solution in terms of how to display a list of ebuilds in one tree in an
>> ordered list.
>
> The mutual blocks can be via the very nature of the name of the ebuild
> (ie, the scm_bbranch), and not via unmaintainable dep blocks in the
> ebuilds. This could be similar to the way SLOTS are handled. In fact,
> as Donnie and Santiago discussed in the other "branch string" thread,
> the concept of SLOTS could be extended to branches with no concept of
> an "upgrade" between them, and them being mutually blocking and
> perhaps blocking the actual package as well.
> Of course this could be extended to apply only to branch ebuilds
> without a version number (where you don't know when the branch will be
> merged), etc.
>
This makes a lot of sense to me.

If different branches of a vcs build are to come into the tree, it only
makes sense they block the main package and each other. Handling that
within the package manager makes sense, since it's information that can be
derived automatically. At a later stage one can envisage branches being
installed to their own prefixes.

>> You are right. But this just shows that named feature branches do not
>> fit the context of this GLEP, as you usually cannot know when a feature
>> will be merged at the time one version is branched.
>
> Completely removing the concept of an "upgrade" from (unversioned?)
> branch ebuilds and making them block all other versions of the package
> will give the task of knowing when a feature has been merged to the
> user itself. Which is after all what one does manually while working
> on branches.
>
++

I don't find the argument for versioning the scm live ebuild compelling.
The point wrt comparison, ie foo-1-scm is < 2.0.1, doesn't seem enough; it'd
be better to slot that imo, and have a slot identifier[1] in the existing
cvs digit space. You could still have gtk-1-cvs, for example, for packages
where slots don't work.

I prefer the way it works now; SLOT and cvs compares later than any other
version in the same slot. (I agree the name is misleading and prefer vcs
since it collides less than other options.)

foo-vcs-rN # standard vcs (i prefer the explicit 0 of current spec)
foo-vcsN-rN # slotted pkg
foo-vcs_branch_FOO-rN # branch
foo-vcsN_branch_STRING-rN

..make sense[2] and cover all the use cases that I have read about so far.
It'd be useful to restrict the STRING to a simple upper case ID with a
length limit; the ebuild description will give more information to a user

A numeric slot id with different branches applying to the same slot would
seem to be enough to track any project over its lifecycle. The id would
only be visible to users choosing to install a live ebuild when the package
is slotted.

The reason I don't think it's a good idea to allow full versioning is that
it seems to be clouding the issue. Packages are available, in slots. If the
user chooses version control, it applies to the slotkg combination, and
beyond that only needs a mechanism to choose which branch to track.
Maintainers need to track ebuild revisions, and all of us, including
package managers, can do with keeping things simple, imo.

[1] Since SLOT is one of the most basic items in an ebuild, it's something
any user making an ebuild is aware of. A vcs ebuild-writer should have no
problem finding a suitable id, especially if it is to go into the tree.

[2] s/vcs/whatever acronym you prefer/
-vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
-rN if missing, is implicit -r0 (compares before explicit)


--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 12:12 AM
Ryan Hill
 
Default scm package version suffix

Ciaran McCreesh wrote:


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


Yeah I abused the _p suffix. My bad.


The whole _p thing only comes up for those very rare (or possibly
non-existent) projects that have patchset branches that are themselves
live.


Actually I was thinking local patchset level. Using a date was silly
though. What I'm doing with gcc locally is currently more like:

gcc-4.2.3_pre20071210_p2

(_preDATE is used solely due to restrictions of toolchain.eclass)

Basically I want to force an update
- when the ebuild is edited (_pre)
- when the patchset is updated (_p)

This naming is pretty much the same as the snapshot ebuilds in
the toolchain overlay, so an -scm suffix to indicate that these

are indeed live SVN ebuilds would be welcome.

I hope this clears up what I meant, to give an example of why one
might want to use version numbers with an -scm suffix.


--
looks like christmas at fifty-five degrees
this latitude weakens my knees
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 07:21 AM
Duncan
 
Default scm package version suffix

"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> posted
8b4c83ad0712101144x19e75accm7845221977a6a73f@mail. gmail.com, excerpted
below, on Tue, 11 Dec 2007 01:14:06 +0530:

> On Dec 10, 2007 8:44 PM, Robert Buchholz <rbu@gentoo.org> wrote:
>> That would still mean everything relies on n ebuilds with mutual
>> blocks. Even if that would work and it block upgrades, it is still not
>> a solution in terms of how to display a list of ebuilds in one tree in
>> an ordered list.
>
> The mutual blocks can be via the very nature of the name of the ebuild
> (ie, the scm_bbranch), and not via unmaintainable dep blocks in the
> ebuilds.

But what about when there's a dependency on any of several branches?
That gets hard to maintain if there are multiple ebuilds with similar
dependencies.

However, that's where virtuals come in. Create a single virtual, depend
on it, and you have a single dependency instead of a whole complex list
to maintain in all the various depending ebuilds. Another alternative of
course is an eclass, inherited by whatever otherwise depending ebuilds,
that manages all the dependencies and blockages all in one spot.

Which just means there are existing solutions for that angle, so it's out
of scope for this GLEP.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 09:59 AM
"Nirbheek Chauhan"
 
Default scm package version suffix

On Dec 11, 2007 5:57 AM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> I don't find the argument for versioning the scm live ebuild compelling.
> The point wrt comparison, ie foo-1-scm is < 2.0.1, doesn't seem enough; it'd
> be better to slot that imo, and have a slot identifier[1] in the existing
> cvs digit space. You could still have gtk-1-cvs, for example, for packages
> where slots don't work.

Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch "awesome-feature" and you know it will be merged in 2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.

>
> I prefer the way it works now; SLOT and cvs compares later than any other
> version in the same slot. (I agree the name is misleading and prefer vcs
> since it collides less than other options.)
>
> foo-vcs-rN # standard vcs (i prefer the explicit 0 of current spec)
> foo-vcsN-rN # slotted pkg

Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say "pkg-scmomg".

> foo-vcs_branch_FOO-rN # branch

Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..

> foo-vcsN_branch_STRING-rN
>
> ..make sense[2] and cover all the use cases that I have read about so far.
> It'd be useful to restrict the STRING to a simple upper case ID with a
> length limit; the ebuild description will give more information to a user

I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.

>
> A numeric slot id with different branches applying to the same slot would
> seem to be enough to track any project over its lifecycle. The id would
> only be visible to users choosing to install a live ebuild when the package
> is slotted.

While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.

- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}

>
> The reason I don't think it's a good idea to allow full versioning is that
> it seems to be clouding the issue. Packages are available, in slots. If the

I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?

> user chooses version control, it applies to the slotkg combination, and
> beyond that only needs a mechanism to choose which branch to track.
> Maintainers need to track ebuild revisions, and all of us, including
> package managers, can do with keeping things simple, imo.
>
> [1] Since SLOT is one of the most basic items in an ebuild, it's something
> any user making an ebuild is aware of. A vcs ebuild-writer should have no
> problem finding a suitable id, especially if it is to go into the tree.
>
> [2] s/vcs/whatever acronym you prefer/
> -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
> -rN if missing, is implicit -r0 (compares before explicit)
>



--
~Nirbheek Chauhan
--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 10:03 AM
"Nirbheek Chauhan"
 
Default scm package version suffix

On Dec 11, 2007 5:57 AM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> I don't find the argument for versioning the scm live ebuild compelling.
> The point wrt comparison, ie foo-1-scm is < 2.0.1, doesn't seem enough; it'd
> be better to slot that imo, and have a slot identifier[1] in the existing
> cvs digit space. You could still have gtk-1-cvs, for example, for packages
> where slots don't work.

Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch "awesome-feature" and you know it will be merged in 2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.

>
> I prefer the way it works now; SLOT and cvs compares later than any other
> version in the same slot. (I agree the name is misleading and prefer vcs
> since it collides less than other options.)
>
> foo-vcs-rN # standard vcs (i prefer the explicit 0 of current spec)
> foo-vcsN-rN # slotted pkg

Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say "pkg-scmomg".

> foo-vcs_branch_FOO-rN # branch

Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..

> foo-vcsN_branch_STRING-rN
>
> ..make sense[2] and cover all the use cases that I have read about so far.
> It'd be useful to restrict the STRING to a simple upper case ID with a
> length limit; the ebuild description will give more information to a user

I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.

>
> A numeric slot id with different branches applying to the same slot would
> seem to be enough to track any project over its lifecycle. The id would
> only be visible to users choosing to install a live ebuild when the package
> is slotted.

While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.

- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}

>
> The reason I don't think it's a good idea to allow full versioning is that
> it seems to be clouding the issue. Packages are available, in slots. If the

I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?

> user chooses version control, it applies to the slotkg combination, and
> beyond that only needs a mechanism to choose which branch to track.
> Maintainers need to track ebuild revisions, and all of us, including
> package managers, can do with keeping things simple, imo.
>
> [1] Since SLOT is one of the most basic items in an ebuild, it's something
> any user making an ebuild is aware of. A vcs ebuild-writer should have no
> problem finding a suitable id, especially if it is to go into the tree.
>
> [2] s/vcs/whatever acronym you prefer/
> -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
> -rN if missing, is implicit -r0 (compares before explicit)
>



--
~Nirbheek Chauhan
--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 10:06 AM
"Nirbheek Chauhan"
 
Default scm package version suffix

On Dec 11, 2007 1:51 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> But what about when there's a dependency on any of several branches?
> That gets hard to maintain if there are multiple ebuilds with similar
> dependencies.

How does it become hard to maintain? Different branch ebuilds are
still the same package. For example:

app-misc/foo-1.2 depends on app-misc/bar

branches won't show up in an upgrade, but you can remove app-misc/bar,
do an `emerge --oneshot =app-misc/bar-scm_bfeature` and app-misc/foo's
dependency will be satisfied.
The idea is that no one would want to automatically upgrade to a
branch (because you cannot define "upgrade" for branches), so make it
manual.



--
~Nirbheek Chauhan
--
gentoo-dev@gentoo.org mailing list
 
Old 12-11-2007, 10:17 AM
Ciaran McCreesh
 
Default scm package version suffix

On Tue, 11 Dec 2007 16:36:51 +0530
"Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> The idea is that no one would want to automatically upgrade to a
> branch (because you cannot define "upgrade" for branches), so make it
> manual.

...and this is why branches shouldn't be treated like versions. They
have their own set of rules and expected behaviours that are best dealt
with by a different proposal.

--
Ciaran McCreesh
 
Old 12-11-2007, 11:10 AM
"Nirbheek Chauhan"
 
Default scm package version suffix

On Dec 11, 2007 4:47 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Tue, 11 Dec 2007 16:36:51 +0530
> "Nirbheek Chauhan" <nirbheek.chauhan@gmail.com> wrote:
> > The idea is that no one would want to automatically upgrade to a
> > branch (because you cannot define "upgrade" for branches), so make it
> > manual.
>
> ...and this is why branches shouldn't be treated like versions. They
> have their own set of rules and expected behaviours that are best dealt
> with by a different proposal.

I made that statement in the context of unversioned branches where you
do not know when the branch will be merged. In the case where you do
know when the branch will be merged, the versioned branch ebuild can
easily be included in the upgrade list via it's version.
So, you cannot "upgrade" to app-misc/foo-scm_bblah but you *can*
upgrade from app-misc/foo-1.2 to app-misc/foo-1.2-scm_bblahblah and
then finally upgrade to app-misc/foo-1.3 when the branch gets merged.

--
~Nirbheek Chauhan
--
gentoo-dev@gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 04:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org