Ryan Hill wrote:
On Fri, 13 Jun 2008 13:35:52 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
Ignoring possible semantic issues for the moment, I'd be against this
simply because it would require the PM to be aware of the current
revision of the repository and to transform it into a integer value
(trivial for SVN, not so trivial for CVS for example). Which in turn
either means that the PM has to internally support the SCMs or support
some new phase functions to extract the revision.
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev.
136737, after the merge do I have gcc-4.4.0_pre136737
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
installed?
it would be gcc-4.4.0_pre1 but you'll have the revision inside the
ebuild as var so you can get it easily. (e.g. the description shows it)
The former, as Marius said, requires knowledge of how to get a sane
revision id from every SCM we want to support to be built into
the package manager.
I wonder if instead of rev id, we could use a timestamp to fill in
_pre. It's not ideal but it narrows the checkout down somewhat.
Also, we could use pkg_info to report revision numbers (for those SCM's
that have such a thing). The combination of the two might be enough -
you'd have the revision you installed, when you installed it, and an
automatic incrementor for those ppl who like those kinds of things.
I like better single digits but it's more or less the same as structure
and code.
If a dev wants to force a reinstall because of ebuild or patch changes
or whatever, they should still be able to use -rX as usual.
A lot of projects work like this:
* trunk/ is current development, and is ahead of any release.
* branches/0.26/ is forked from trunk/ when 0.26 is released, and is
equal to or ahead of any 0.26 release.
How does your proposal handle this?
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released. I already need to do this with my live ebuilds. Of
course, with some projects you never know if the next version will be
0.26.1, 0.27, or 0.3, or 1.0...
That's an upstream issue, all we should care is about getting a version
value that makes sense for us, better if it does for them.
As for an ebuild tracking trunk, I guess we're back to -9999.live. ;P
or just keep in mind that even trunk changes enough that you need to
update the ebuild thus makes sense use a next supposed version.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
