On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote: > > On Sat, 14 Jun 2008 10:19:32 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > >>> 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) > > > > And when would gcc-4.4.0_pre2 become available? > > It will be available once you trigger again the generation or if you > put a normal ebuild with such name. So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. I think the request to create some kind of auto-updating system for live ebuilds is a red herring, and will make finding a reasonable solution much much harder than it should be. If people want to auto-update their live ebuilds they can simply put them in a cron job. -- 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
