1 |
Ryan Hill wrote: |
2 |
> On Sat, 14 Jun 2008 17:55:27 +0200 |
3 |
> Luca Barbato <lu_zero@g.o> wrote: |
4 |
> |
5 |
>> Ryan Hill wrote: |
6 |
>>> So every user will have a different _preN version which would vary |
7 |
>>> depending on how often they rebuild the package and that has |
8 |
>>> absolutely no correlation with the revision number of the upstream |
9 |
>>> codebase. I'm sorry, but that's unacceptable. :/ |
10 |
>> You'd like to have the cflags and ldflags embedded in the name for |
11 |
>> the same reason? |
12 |
> |
13 |
> There's no need to set up a strawman. I expect that everyone |
14 |
> installing a version of a package is building from the same sources. |
15 |
> Do you really not see a problem here? |
16 |
|
17 |
Well the idea is to have the revision/reference behave like CFLAGS and |
18 |
src_uri such variables, sorry if I just said that backwards. |
19 |
|
20 |
> Okay, taking a different approach, what does an auto-incrementing |
21 |
> suffix gain us? The ability to auto-merge a live ebuild at regular |
22 |
> intervals? That's something that can easily be achieved without |
23 |
> mucking about mangling CPVs, in any implementation we decide on. What |
24 |
> is it about your particular idea that makes it worth the numerous |
25 |
> disadvantages that we've pointed out? |
26 |
|
27 |
I don't see disadvantages, all I wanted is a simple way to archive this: |
28 |
|
29 |
# emaint -r ffmpeg |
30 |
|
31 |
# emerge ffmpeg -p |
32 |
|
33 |
[ebuild U ] media-video/ffmpeg-0.4.9_pre1235 [0.4.9_pre1234] [1] |
34 |
|
35 |
[1] from ffmpeg-0.4.9.live |
36 |
|
37 |
# emerge ffmpeg |
38 |
|
39 |
fails, configure changed |
40 |
|
41 |
# vim /usr/portage/media-video/ffmpeg-0.4.9.live.ebuild *1* |
42 |
|
43 |
fix it |
44 |
|
45 |
# emerge ffmpeg -L |
46 |
|
47 |
builds as should test suite ok, further tests ok, everything builds |
48 |
using it. |
49 |
|
50 |
# egen ffmpeg 0.4.9_p${date} *2* |
51 |
|
52 |
# scp /usr/portage/distfiles/ffmpeg-0.4.9_p${date}.tar.bz2 |
53 |
dev.gento.org:place |
54 |
# cp usr/portage/media-video/ffmpeg/ffmpeg-0.4.9_p${date}.ebuild |
55 |
/var/cvs/gentoo-x86/media-video/ffmpeg/ |
56 |
|
57 |
# cd /var/cvs/gentoo-x86/media-video/ffmpeg/ |
58 |
|
59 |
# cvs add ffmpeg-0.4.9_p${date}.ebuild |
60 |
|
61 |
# echangelog "New revision" && repoman ci -m "New revision" |
62 |
|
63 |
[1] or just ffmpeg-0.4.9.live if you like better. |
64 |
[2] emaint -g instead of egen |
65 |
|
66 |
I do not want end users using this stuff. |
67 |
|
68 |
>>> If a user reports a bug in package-1.1_pre6, how do you determine |
69 |
>>> what revision he has installed? How can you even tell it's an scm |
70 |
>>> ebuild? |
71 |
>> You can. The generated ebuild must have a reference to the checkout. |
72 |
> |
73 |
> This is the first time you've mentioned this. |
74 |
|
75 |
really? btw s/generated/recorded in the vdb. |
76 |
|
77 |
> Where would you find such information? |
78 |
|
79 |
from the vcs since on unpack or before I have to have the sources and |
80 |
thus the revision. |
81 |
|
82 |
> How would you know that the ebuild the user is using is a generated ebuild, |
83 |
> and not just a standard ebuild that happens to end in _pre6? |
84 |
|
85 |
Being the maintainer I should know what's in the tree. If somebody |
86 |
happens to use an overlay that shadows the main tree how you'd be able |
87 |
to tell the difference from foo-1.2.3 and foo-1.2.3? |
88 |
|
89 |
> How would that information get into the ebuild? Would |
90 |
> it have to come from the various VCS eclasses? |
91 |
|
92 |
Right. |
93 |
|
94 |
> What about those that don't have a way of getting at the revision number (like say |
95 |
> cvs.eclass)? |
96 |
|
97 |
A timestamp should do, I cannot think anything better. You want to have |
98 |
in the recorded ebuild everything useful to replay the process. |
99 |
|
100 |
> Would it have to be placed there by the package manager? |
101 |
|
102 |
Yes. |
103 |
|
104 |
> If so, then we're back to having to implement support for every VCS |
105 |
> inside the PM. |
106 |
|
107 |
Having support inside the template to have such information in a |
108 |
variable you can save (as CFLAGS and friends) doesn't require this =) |
109 |
|
110 |
>>> If I want to report a bug I find to upstream, how to I know what |
111 |
>>> revision I have? Yes there are hacks like ESCM_LOGDIR, but they're |
112 |
>>> different for every SCM and you have to opt-in to use them. Most |
113 |
>>> people don't even know about them. |
114 |
>> The generated ebuild contains pretty much everything you need to fill |
115 |
>> a bugreport. |
116 |
> |
117 |
> Could you please provide an example of a generated ebuild so we can see |
118 |
> what kinds of info it contains? |
119 |
|
120 |
I phrased that badly. |
121 |
|
122 |
we have some phases: |
123 |
|
124 |
given we have a simple ebuild |
125 |
|
126 |
Once we get a new template we can trigger a phase that makes the pm |
127 |
consider the existence of an ebuild alike the current -9999 ones: they |
128 |
pick the tip of the branch chosen from the repository defined. |
129 |
But with the version generated as already said. |
130 |
|
131 |
If such ebuild get chosen for merge it behaves pretty much like the |
132 |
current ones, but the PM stores additional informations in the vdb |
133 |
(using current subversion.eclass as example it records the equivalent of |
134 |
ESVN_REVISION). Such informations let you know how to reproduce the |
135 |
build and let you generate a static snapshot automatically. |
136 |
|
137 |
A dirty and simple way to implement this stuff right now (abusing |
138 |
everything) is to: |
139 |
|
140 |
have a script that scans the tree for .live templates and generates |
141 |
ebuild out of them and places them in an overlay |
142 |
|
143 |
have those ebuild rewrite themselves in the vdb adding the information |
144 |
needed. |
145 |
|
146 |
Making it less dirty requires adding a new phase and possibly some new |
147 |
functions as ciaranm suggested. |
148 |
|
149 |
-- |
150 |
|
151 |
Luca Barbato |
152 |
Gentoo Council Member |
153 |
Gentoo/linux Gentoo/PPC |
154 |
http://dev.gentoo.org/~lu_zero |
155 |
|
156 |
-- |
157 |
gentoo-dev@l.g.o mailing list |