1 |
On Wed, 11 Jul 2012 10:35:32 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Wed, Jul 11, 2012 at 10:09 AM, Michał Górny <mgorny@g.o> |
5 |
> wrote: |
6 |
> > On Tue, 10 Jul 2012 21:23:39 +0200 |
7 |
> > Thomas Sachau <tommy@g.o> wrote: |
8 |
> >> As discussed on IRC, there is still no consensus for installing the |
9 |
> >> udev files with systemd, which is the beginning for the block and |
10 |
> >> the virtual. So we should first sort that point out, before we |
11 |
> >> even start to think about an ebuild for an udev virtual. |
12 |
> > |
13 |
> > Do you have a technical or policy reason prohibiting me from |
14 |
> > maintaining a systemd ebuild following the upstream policies? |
15 |
> > |
16 |
> |
17 |
> It sounds like we have two packages that COULD provide udev - udev and |
18 |
> systemd. If we decide for both of them to provide udev then we need a |
19 |
> virtual and they need to block (which should make switching more fun). |
20 |
> If we decide to keep using the udev package to install udev then we |
21 |
> don't need a virtual. |
22 |
|
23 |
No, switching is no fun. It's plain simple with weak blockers. It's |
24 |
even their purpose. |
25 |
|
26 |
> I'd view this like the split kde ebuilds. Upstream ships a monster |
27 |
> tarball, and we install it in chunks. Just because upstream ships |
28 |
> both packages together doesn't require us to install them together. |
29 |
> From a code-reuse standpoint and ease of transition standpoint it |
30 |
> makes sense to keep them split, as long as we can have everybody |
31 |
> continue to use the same udev codebase. |
32 |
|
33 |
Are you aware how much additional code and maintenance does keeping two |
34 |
hacked build systems introduce? One of things I don't want to do is |
35 |
keeping the list of *all other* systemd targets up-to-date, |
36 |
and installing them all by hand. |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Michał Górny |