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? The latter would be quite a nightmare. A bug report about an error in package-1.1_pre6 isn't really helpful when everyone's _pre6 is a completely different revision. 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. > * How are you planning to handle reinstalls? Should installing world > always reinstall live things? Never? Or what? > > * How are live ebuilds selected by the package manager? How are reinstalls handled for -9999 ebuilds now? I wouldn't think it would need to change. You'd have to unmask the live ebuild, then it would only be reinstalled if you used --emptytree or specifically asked for it on the command line. I'm not sure this preN+1 thing makes sense. If a user wants to automatically update a live ebuild every week, etc, they need to learn how to use cron. :P 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... As for an ebuild tracking trunk, I guess we're back to -9999.live. ;P -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
