1 |
On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau <tommy@g.o> wrote: |
2 |
> Michał Górny schrieb: |
3 |
>> On Tue, 10 Jul 2012 21:23:39 +0200 |
4 |
>> Thomas Sachau <tommy@g.o> wrote: |
5 |
>> |
6 |
>>> Michał Górny schrieb: |
7 |
>>>> Hello, all. |
8 |
>>>> |
9 |
>>>> Since nowadays udev is bundled within systemd, we start having two |
10 |
>>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making |
11 |
>>>> the long story short, I would like to introduce a virtual for |
12 |
>>>> libudev which would pull in either of those two. |
13 |
>>>> |
14 |
>>>> There are three USE flags used in conditionals when depending on |
15 |
>>>> udev: |
16 |
>>>> - gudev - for glib wrapper on udev, |
17 |
>>>> - hwdb - to pull in hwids, |
18 |
>>>> - static-libs. |
19 |
>>>> |
20 |
>>>> The former two were previously provided by 'extras' USE flag, |
21 |
>>>> and the third was unconditional. |
22 |
>>>> |
23 |
>>>> I'm attaching an example virtual/libudev which does the job. Sadly, |
24 |
>>>> because of the 'extras' compatibility it's a big ugly conditional. |
25 |
>>>> |
26 |
>>>> An alternative would be to provide separate virtual/libudev |
27 |
>>>> and virtual/libgudev; and maybe changing ebuilds not to depend on |
28 |
>>>> [hwids] but rather pull in sys-apps/hwids directly (since that's |
29 |
>>>> what the flag does). |
30 |
>>>> |
31 |
>>>> What are you thoughts? |
32 |
>>> |
33 |
>>> As discussed on IRC, there is still no consensus for installing the |
34 |
>>> udev files with systemd, which is the beginning for the block and the |
35 |
>>> virtual. So we should first sort that point out, before we even start |
36 |
>>> to think about an ebuild for an udev virtual. |
37 |
>> |
38 |
>> Do you have a technical or policy reason prohibiting me from maintaining |
39 |
>> a systemd ebuild following the upstream policies? |
40 |
> |
41 |
> How about this simple one: The udev ebuild does already install udev, so |
42 |
> why should we have another package also installing the same thing, |
43 |
> resulting in a blocker, the need to switch from one package to another |
44 |
> and the need for package maintainers to switch their dependencies? |
45 |
|
46 |
Just to put a number to this, there are currently 126 packages in the |
47 |
tree with a dependency on sys-fs/udev. |
48 |
|
49 |
> Since William already said, that he will move the udev installation to |
50 |
> /usr/lib, i dont see any technical reason left to not simply depend on |
51 |
> the udev ebuild. |
52 |
> And if you fear issues about not knowing which parts to install, then |
53 |
> just check the files installed by the udev ebuild, remove them from your |
54 |
> systemd ebuild and you are done. |
55 |
|
56 |
This means that systemd users end up building the udev components |
57 |
twice, and throwing away the second copy. You don't seem to care about |
58 |
this, but I think it is a valid concern. |
59 |
|
60 |
I am guessing that systemd is or will become very sensitive to any |
61 |
change in udev's API, so each systemd version would have to depend |
62 |
exactly on the corresponding udev version. This means that a systemd |
63 |
version bump could be stuck waiting on the corresponding udev version. |
64 |
|
65 |
I also wonder if incompatibilities may be introduced by passing |
66 |
different build options in the udev and systemd ebuilds due to having |
67 |
different use flags enabled, for example. This can be worked around |
68 |
with use-deps of course, but it is yet another pain point for the |
69 |
systemd maintainer. |
70 |
|
71 |
If there were a way to tell the systemd build system to build against |
72 |
the "system udev", that might avoid the issue, but I doubt systemd |
73 |
upstream would implement such a thing. |
74 |
|
75 |
Personally, I think a consolidated systemd/udev package is the best |
76 |
way to go here. Short of that, the virtual + blockers seems like an |
77 |
acceptable solution. |