| 1 |
On Mon, Aug 6, 2012 at 6:20 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Most importantly, this allows us to easily find out which packages |
| 3 |
> install such files and perform global operations on them. For example, |
| 4 |
> if a particular user had systemd locations in INSTALL_MASK and changed |
| 5 |
> his mind, he can easily update his system by rebuilding all packages |
| 6 |
> inheriting systemd.eclass. |
| 7 |
> |
| 8 |
> If all packages installing udev rules start inheriting it, the above |
| 9 |
> will no longer be correct. Also, the opposite way -- rebuilding |
| 10 |
> packages installing udev rules -- won't be that easy. |
| 11 |
|
| 12 |
This seems like a bit of overloading. Right now we really lack a good |
| 13 |
way to figure out what packages COULD install files in a given place - |
| 14 |
we can only figure out which ones have installed files in that |
| 15 |
location on our own systems. |
| 16 |
|
| 17 |
If we really want that capability then I think the solution is to |
| 18 |
design it thoughtfully. Sure, some detective work with eclass |
| 19 |
inheritance might give us clues, but I wouldn't let it be a big driver |
| 20 |
behind how we use and design eclasses. That said, there might be |
| 21 |
other valid reasons for keeping udev and systemd separate |
| 22 |
eclass-wise... |
| 23 |
|
| 24 |
Rich |
Archives