| 1 |
On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka |
| 2 |
<kensington@g.o> wrote: |
| 3 |
> |
| 4 |
> Ditching implicit dependencies is an interesting idea but not practical. |
| 5 |
> Nobody wants to the laundry list, and there's little benefit in |
| 6 |
> maintaining a virtual/system clone of @system. |
| 7 |
> |
| 8 |
|
| 9 |
Well, the idea would be to maintain the virtual INSTEAD of @system, or |
| 10 |
have @system just pull in the virtual and make some arch-specific |
| 11 |
additions. |
| 12 |
|
| 13 |
As far as benefits go, they include: |
| 14 |
1. No need to have multiple ways of grouping packages. |
| 15 |
2. You can more than one virtual, so that you could just pull in the |
| 16 |
super-lazy equivalent to @system, or maybe you just pull in POSIX+bash |
| 17 |
and C++ or something like that. |
| 18 |
3. You can split up that virtual so that convenience packages like |
| 19 |
ssh aren't in the same virtual as widespread dependencies like |
| 20 |
bash/zlib/glibc/gcc/etc. There is no reason that you can't build |
| 21 |
openssh in parallel, but right now you can't because we lump it in |
| 22 |
with glibc. |
| 23 |
4. You can choose when to use the virtual at all, versus explicitly |
| 24 |
naming all dependencies. |
| 25 |
|
| 26 |
For 99% of packages it would be the same. We could even have that |
| 27 |
dependency added automatically if something isn't done in the ebuild |
| 28 |
to disable it, which would make ebuilds work the same as they do now. |
| 29 |
However, for the packages that are actually in @system we could list |
| 30 |
explicit dependencies and then portage would actually be able to |
| 31 |
handle some things automatically. Also, by using virtuals that are |
| 32 |
the same across all archs, we have a bit more consistency. |
| 33 |
|
| 34 |
Policy-wise, though, the status quo isn't that bad. You never have to |
| 35 |
list dependencies that are in @system, full stop. You can list a |
| 36 |
dependency that is in @system anytime you want to, full stop. |
| 37 |
|
| 38 |
That is, it is never right or wrong to list an unversioned dependency |
| 39 |
that is in @system. Sometimes doing one or the other is advantageous |
| 40 |
(such as when you have a versioned dependency, or a virtual is in |
| 41 |
@system but you need a specific implementation, or you want to use a |
| 42 |
slot-op dep). I'm fine with examples, but they shouldn't be firm |
| 43 |
rules, just helpful guidelines. |
| 44 |
|
| 45 |
-- |
| 46 |
Rich |
Archives