Ryan Hill wrote:
> On Sat, 14 Jun 2008 17:55:27 +0200
> Luca Barbato <lu_zero@g.o> wrote:
> 
>> Ryan Hill wrote:
>>> 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. :/
>> You'd like to have the cflags and ldflags embedded in the name for
>> the same reason?
> 
> There's no need to set up a strawman.  I expect that everyone
> installing a version of a package is building from the same sources.
> Do you really not see a problem here?

Well the idea is to have the revision/reference behave like CFLAGS and 
src_uri such variables, sorry if I just said that backwards.

> Okay, taking a different approach, what does an auto-incrementing
> suffix gain us?  The ability to auto-merge a live ebuild at regular
> intervals?  That's something that can easily be achieved without
> mucking about mangling CPVs, in any implementation we decide on.  What
> is it about your particular idea that makes it worth the numerous
> disadvantages that we've pointed out?

I don't see disadvantages, all I wanted is a simple way to archive this:

# emaint -r ffmpeg

# emerge ffmpeg -p

[ebuild     U ] media-video/ffmpeg-0.4.9_pre1235 [0.4.9_pre1234] [1]

[1] from ffmpeg-0.4.9.live

# emerge ffmpeg

fails, configure changed

# vim /usr/portage/media-video/ffmpeg-0.4.9.live.ebuild *1*

fix it

# emerge ffmpeg -L

builds as should test suite ok, further tests ok, everything builds 
using it.

# egen ffmpeg 0.4.9_p${date} *2*

# scp /usr/portage/distfiles/ffmpeg-0.4.9_p${date}.tar.bz2 
dev.gento.org:place
# cp usr/portage/media-video/ffmpeg/ffmpeg-0.4.9_p${date}.ebuild 
/var/cvs/gentoo-x86/media-video/ffmpeg/

# cd /var/cvs/gentoo-x86/media-video/ffmpeg/

# cvs add ffmpeg-0.4.9_p${date}.ebuild

# echangelog "New revision" && repoman ci -m "New revision"

[1] or just ffmpeg-0.4.9.live if you like better.
[2] emaint -g instead of egen

I do not want end users using this stuff.

>>> 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?
>> You can. The generated ebuild must have a reference to the checkout.
> 
> This is the first time you've mentioned this.

really? btw s/generated/recorded in the vdb.

> Where would you find such information?

from the vcs since on unpack or before I have to have the sources and 
thus the revision.

> How would you know that the ebuild the user is using is a generated ebuild,
> and not just a standard ebuild that happens to end in _pre6?

Being the maintainer I should know what's in the tree. If somebody 
happens to use an overlay that shadows the main tree how you'd be able 
to tell the difference from foo-1.2.3 and foo-1.2.3?

> How would that information get into the ebuild?  Would
> it have to come from the various VCS eclasses?

Right.

> What about those that don't have a way of getting at the revision number (like say
> cvs.eclass)?

A timestamp should do, I cannot think anything better. You want to have 
in the recorded ebuild everything useful to replay the process.

> Would it have to be placed there by the package manager?

Yes.

> If so, then we're back to having to implement support for every VCS
> inside the PM.

Having support inside the template to have such information in a 
variable you can save (as CFLAGS and friends) doesn't require this =)

>>> 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.
>> The generated ebuild contains pretty much everything you need to fill
>> a bugreport.
> 
> Could you please provide an example of a generated ebuild so we can see
> what kinds of info it contains?

I phrased that badly.

we have some phases:

given we have a simple ebuild

Once we get a new template we can trigger a phase that makes the pm 
consider the existence of an ebuild alike the current -9999 ones: they 
pick the tip of the branch chosen from the repository defined.
But with the version generated as already said.

If such ebuild get chosen for merge it behaves pretty much like the 
current ones, but the PM stores additional informations in the vdb 
(using current subversion.eclass as example it records the equivalent of 
ESVN_REVISION). Such informations let you know how to reproduce the 
build and let you generate a static snapshot automatically.

A dirty and simple way to implement this stuff right now (abusing 
everything) is to:

have a script that scans the tree for .live templates and generates 
ebuild out of them and places them in an overlay

have those ebuild rewrite themselves in the vdb adding the information 
needed.

Making it less dirty requires adding a new phase and possibly some new 
functions as ciaranm suggested.

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@g.o mailing list