1 |
[GRR!! Insane quote ordering for proper contextual replies rearranged to |
2 |
conventional.] |
3 |
|
4 |
Dice R. Random posted |
5 |
<d9b9989b0604280243h2f97255dt285379a59da555ef@××××××××××.com>, excerpted |
6 |
below, on Fri, 28 Apr 2006 02:43:44 -0700: |
7 |
> |
8 |
> On 4/28/06, Steve Herber <herber@×××××.com> wrote: |
9 |
>> Portage is great but... it depends upon a person to create a new ebuild |
10 |
>> when a new version is released. |
11 |
>> |
12 |
>> There are two times when I would like a script to create an ebuild |
13 |
>> automatically. I wonder if anyone has such a script or if someone is |
14 |
>> working on such a script. |
15 |
>> |
16 |
>> Often a new software release is available from the home site but |
17 |
>> portage has not been updated. I would like a script that would: |
18 |
>> |
19 |
>> check the source repository for a package |
20 |
>> find the latest version |
21 |
>> if the repository has a newer version |
22 |
>> create an overlay with an ebuild for the new version |
23 |
>> try to build the new package |
24 |
|
25 |
This would be relatively easy to automate, due to the standard bump |
26 |
procedure below. It wouldn't always work, and the risk for even trying it |
27 |
would be entirely the user's, because in some cases such a procedure WOULD |
28 |
break the system, due to changes between versions that weren't |
29 |
accounted for by the automated process, but it would be relatively easy to |
30 |
write a script that would work for most minor bumps anyway, a reasonable |
31 |
percentage of the time, risky tho it would indeed be to just blindly run |
32 |
it. |
33 |
|
34 |
>> Other times I will hear about a new software package and I want to try |
35 |
>> it out. I would like a script that would take a URL for the home site |
36 |
>> as an argument and then would operate like the script above. |
37 |
|
38 |
This simply couldn't be automated in a sane manner. There's too much |
39 |
variability in the way various things build, and too much risk in simply |
40 |
assuming the normal otherwise automatable procedure will work, and will |
41 |
not do something strange enough that it could be harmful to a working |
42 |
system. An initial build for an application isn't a simple matter. One |
43 |
must decide where things should go and supply the appropriate parameters |
44 |
to have it install there. One must check that the licensing is suitable |
45 |
for Gentoo, and further, whether Gentoo can mirror the sources or whether |
46 |
they have to be fetched directly from upstream due to licencing, possibly |
47 |
manually, if the licensing is strict enough. One must verify the |
48 |
setup/unpack/configure/compile/install/qmerge steps and create |
49 |
non-defaults for anything that doesn't work normally. One must ensure |
50 |
that the sequence doesn't violate the non-interactive rules of portage. |
51 |
One must ensure the merged application is sufficiently configured to "just |
52 |
work" out of the box, with no additional configuration, if at all possible |
53 |
(obviously it's not going to be possible with things like cups, where the |
54 |
user must configure the printers they use as appropriate). One must make |
55 |
some attempt to verify sane compile settings and that the package will use |
56 |
those supplied by portage over its default settings. One must further |
57 |
verify that "normal" CFLAGS/CXXFLAGS actually work. One must evaluate |
58 |
dependencies both optional and required, setting the correct build and |
59 |
runtime dependencies, and setting up USE flags as appropriate for the |
60 |
optional ones. One must... One must... One must... Finally, appropriate |
61 |
patches must be devised if the package doesn't by default pass any of |
62 |
these steps, such that it does. |
63 |
|
64 |
Really, the devs do more for you by supplying Gentoo than picking their |
65 |
nose all day. Don't you think if it were that easy (or even /possible/) |
66 |
to automate creating an ebuild for a any random product out there, that |
67 |
they would have such a system by now? I'm not a dev, but if I was, I'd be |
68 |
insulted by just how lazy or stupid you obviously think they are, lazy if |
69 |
you think they have such an approach and are simply hiding it as some big |
70 |
secret, so they can do the easy stuff and make it look hard, stupid if you |
71 |
think it's possible to automate the thing, and they haven't done it. |
72 |
|
73 |
Really, if there's no ebuild available at all, the user is best advised to |
74 |
read the documentation to learn of any gotchas, then follow thru on the |
75 |
steps manually, such that he can watch what's going on and see where any |
76 |
breakage occurs, and attempt to fix it at that point. |
77 |
|
78 |
>> If such scripts were available, it would be much easier to check out |
79 |
>> new software releases. I could imagine a system that would scan |
80 |
>> listings from freshmeat or other non-Gentoo site, build the ebuild and |
81 |
>> try the package. In the simplest case you would get a go/no-go answer. |
82 |
>> For the packages that download and build, you could try it out. If it |
83 |
>> failed you could ignore it or try to figure out the problem. |
84 |
|
85 |
If it failed, you could indeed try to figure out the problem -- |
86 |
potentially try to figure out why nothing you try to run works any more, |
87 |
and your system won't boot, because the automated script created an ebuild |
88 |
that blindly deleted /usr/bin/*, or something equally dangerous to a |
89 |
system, because someone thought it was a bright idea to trust the build to |
90 |
an automated script, sight entirely unseen, README and INSTALL entirely |
91 |
unread! |
92 |
|
93 |
There's simply no sane nor safe way to automate that stuff. For something |
94 |
with an existing ebuild that might just need bumped, sure. For something |
95 |
without an existing ebuild, I must conclude you really hadn't thought the |
96 |
implications of what you were asking for thru AT ALL!! |
97 |
|
98 |
> I don't know about an automated process, there are a lot of variables |
99 |
> that can factor into a version bump. However, for many simple |
100 |
> packages, i.e. things that are not heavily patched or that do not have |
101 |
> changing software requirements, it is usually sufficient to simply |
102 |
> copy the old ebuild over to the new version name. |
103 |
> |
104 |
> Example, suppose net-www/fooapp has recently been bumped from version |
105 |
> 1.001 to 1.002. You could do the following: |
106 |
> |
107 |
> mkdir -p /usr/local/portage/net-www |
108 |
> cp -r /usr/portage/net-www/fooapp /usr/local/portage/net-www |
109 |
> cd /usr/local/portage/net-www/fooapp |
110 |
> cp fooapp-1.001.ebuild fooapp-1.002.ebuild |
111 |
> ebuild fooapp-1.002.ebuild digest |
112 |
> emerge -auv fooapp |
113 |
> |
114 |
> The reason for copying the entire /usr/portage/net-www/fooapp |
115 |
> directory tree over is that there may be some patches or configuration |
116 |
> files or such under the files/ subdirectory which are required by the |
117 |
> ebuild. As I said, this procedure works a good 8 or 9 times out of 10 |
118 |
> with simple ebuilds, sometimes some slight modifications are necessary |
119 |
> and other times the modifications may be quite extensive. |
120 |
|
121 |
A solid idea, the steps of which are done by many, but a couple |
122 |
modifications make it a bit better. |
123 |
|
124 |
Instead of copying over the entire dir, create the dir in the overlay (if |
125 |
you don't already have it from a previous version), and copy over the |
126 |
ebuild you intend to bump. You don't have to worry about previous |
127 |
versions, or the changelog, metadata, or manifest files, since you the |
128 |
former two are simply informational and the latter will be recreated. |
129 |
Instead of copying over the files dir, make a symlink to the existing one |
130 |
in the regular portage tree. (If you have any of your own patches or |
131 |
modify any existing ones, create a different dir for those, and edit the |
132 |
ebuild accordingly.) |
133 |
|
134 |
Since the files dir is a symlink, it will automatically change as the |
135 |
portage tree changes. Thus, if patches are changed or added in the Gentoo |
136 |
tree, the copy in the overlay will stay current, and any remerge or the |
137 |
next bump will use the new versions. In some cases that's critical, as it |
138 |
could mean you get security patches added since the static creation of the |
139 |
overlay. |
140 |
|
141 |
Doing it this way, only copying the specific ebuild you'll be working on, |
142 |
bumping or whatever, and using a symlink for the files dir, avoids the |
143 |
risk of overwriting any work you've done on the same package previously, |
144 |
that you may wish to save. It's also more space efficient. |
145 |
|
146 |
... |
147 |
|
148 |
In any case, with or without my changes, that the steps can be laid out as |
149 |
a series of coommands like that indicates they can be made into a script. |
150 |
It's an exercise left to the reader, then, to create a script that takes |
151 |
the CPV (category/package-version) of the existing ebuild, and the version |
152 |
of the the target ebuild, as command line parameters, and executes the |
153 |
sequence of coommands necessary to end up with the bumped ebuild ready to |
154 |
go in the overlay. Depending on how fancy you want to make the script, |
155 |
with or without a --help output, with or without validity checking and |
156 |
handling any possible errors, with or without the overlay location |
157 |
hard-coded into the script vs. configurable using a config file or a |
158 |
command line option, and depending on how good you are with bash scripting |
159 |
or scripting in your language of choice (perl, python, whatever), reading |
160 |
this thread could have taken you longer than creating the script will. |
161 |
|
162 |
> BTW, if you do discover a package that has a new version and you get a |
163 |
> good working ebuild for the new version make sure that you post it to |
164 |
> bugzilla so that a developer can get it into the tree. |
165 |
|
166 |
Always a good recommendation! =8^) |
167 |
|
168 |
-- |
169 |
Duncan - List replies preferred. No HTML msgs. |
170 |
"Every nonfree program has a lord, a master -- |
171 |
and if you use the program, he is your master." Richard Stallman in |
172 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
173 |
|
174 |
|
175 |
-- |
176 |
gentoo-amd64@g.o mailing list |