1 |
On Thu, 16 Jun 2005 13:50:47 -0300 |
2 |
Rafael Espíndola <rafael.espindola@×××××.com> wrote: |
3 |
|
4 |
> Has someone worked on changing ebuild so that it could create |
5 |
> many binary packages from one source? |
6 |
|
7 |
A less intrusive solution (well, i think, although it would |
8 |
still be an important change) would be to have some kind of |
9 |
special flags dedicated to a new ebuild phase: pkg_filter. Lets |
10 |
call them FILTER flags (i will often use the server/client |
11 |
example in the above, but that's just an example sure). |
12 |
|
13 |
The main differences with USE flags would be: |
14 |
- only work at pkg_filter time, so the would not have any |
15 |
influence on compile-time or the contents of binary packages |
16 |
- accessible through a different bash test function ("filter" |
17 |
instead of "use") |
18 |
- not recorded in binary packages metadata, so its really the |
19 |
target host's FILTER flags that are taken into account, and not |
20 |
the building host's ones |
21 |
- they would sound "negative" rather than "positive", there |
22 |
purpose being to remove things |
23 |
- they would be a bit simpler (probably no need to have some |
24 |
defaults in profiles, no auto-triggering à la use.defaults, etc.) |
25 |
|
26 |
Other than that, they would be similar (have some filter.desc |
27 |
and filter.local.desc, have a package.filter config file in /etc/ |
28 |
portage, be recorded in /var/db/pkg, add some colored output to |
29 |
`emerge -pv`, etc). |
30 |
|
31 |
The pkg_filter() step would happen somewhere after src_install (or |
32 |
binary package unpacking) and before the merge. Not sure whether |
33 |
it should be before or after pkg_preinst (oh, and btw, if I |
34 |
suggest not using pkg_preinst, that's because it really should |
35 |
be sandboxed). |
36 |
|
37 |
Based on this FILTER flags, pkg_filter would apply some kind of |
38 |
ebuild-specific contents filtering, by deleting stuffs in the |
39 |
the image directory. Example for openssh: |
40 |
|
41 |
pkg_filter() { |
42 |
if filter 'noserver' ; then |
43 |
rm ${D}usr/bin/sshd |
44 |
rm ${D}etc/init.d/sshd |
45 |
rm ${D}etc/conf.d/sshd |
46 |
... |
47 |
fi |
48 |
} |
49 |
|
50 |
So, this proposal is really about putting in ebuilds the logic to |
51 |
replace some of the INSTALL_MASK or overlayed ebuild hacks. I |
52 |
don't think it's the right thing to put that completly on user's |
53 |
responsability like it is now when it's such common needs like |
54 |
installing a simple ssh or samba client for instance. |
55 |
|
56 |
The idea comes from rereading an old thread about server/client |
57 |
USE flags actually: |
58 |
http://thread.gmane.org/gmane.linux.gentoo.devel/13501 |
59 |
Some of the point made there that i think it would solve are: |
60 |
|
61 |
* splitting ebuilds into something-client and something-server is |
62 |
not the right approach from several maintainers point-of-view |
63 |
(more work on updates, lots of duplicate compile time, etc.) |
64 |
=> FILTER flags would solve the duplicate compile workload at |
65 |
least. It would still give more work to maintainers tho, to |
66 |
write the pkg_filter() functions where needed, and to test the |
67 |
package in several FILTER configuration. But I tend to think |
68 |
that it's much less work than a split: |
69 |
- you keep a single ebuild |
70 |
- you don't have to change anything in src_*() |
71 |
- it's not critical if you miss some files in pkg_filter; |
72 |
having forgotten to delete the sshd manpage in the above example |
73 |
won't break anything. Neither will missing a something.so.1.0 |
74 |
renaming to .so.1.1 when bumping a package. All one has to take |
75 |
real care of is to delete only things that he is sure are used |
76 |
only by the package part he want to filter out, but if in doubt, |
77 |
the safer approach is the easiest one: not deleting the file. |
78 |
|
79 |
* USE flags are not neither the right approach (for some no-more- |
80 |
valid concerns, like their globalness at that time, but also for |
81 |
some still valid ones like "i will have to recompile the whole |
82 |
samba if i suddenly decide to add a client to my server") |
83 |
=> with FILTER flags, as soon as you keep binary packages, |
84 |
reinstalling samba without "noclient" doesn't imply |
85 |
recompilation. Also, the same GRP packages will be good for both |
86 |
people who want a samba server and those who want a samba client. |
87 |
|
88 |
|
89 |
One last thing I've not talked about are dependencies. A very |
90 |
valid point made against a "server" USE flag was that it sometimes |
91 |
happen that a package can depend on foo/bar being installed with |
92 |
+server. The issue still holds with FILTER flags sure. But i |
93 |
think portage devs are working on solving that for USE flags |
94 |
(would be something RDEPEND="foo/bar:flag"), and if that's true, |
95 |
then it could easily be extended to FILTER flags too i think. |
96 |
Something like RDEPEND="foo/bar:!noserver" (or maybe the opposite |
97 |
way: don't accept any filter flag per default, and specify in dep |
98 |
atoms the acceptable ones). |
99 |
And again about dependencies, there the question whether RDEPENDs |
100 |
could be trimed down when filtering parts of a package (in case |
101 |
libfoobar is only used by a server daemon that won't be |
102 |
installed for instance). Here, i don't really have an opinion |
103 |
about whether it worths taking FILTER flag into account. Again, |
104 |
to much RDEPEND is not critical. But it would be possible to deal |
105 |
with that anyway: conditionnal RDEPENDs could be interpreted |
106 |
with the USE flag (the one recorded from compile-time in case |
107 |
of binary package) plus the target host FILTER flags, whereas |
108 |
DEPENDs would only take USE flags into account. |
109 |
|
110 |
|
111 |
And that's it. Sorry for the long email, writing it made me think |
112 |
of a few more things than i had to say at the beginning. |
113 |
|
114 |
-- |
115 |
TGL. |
116 |
|
117 |
-- |
118 |
gentoo-dev@g.o mailing list |