Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <[EMAIL PROTECTED]> 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
--
[email protected] mailing list
