| 1 |
On Wednesday 25 January 2006 16:19, Donnie Berkholz wrote: |
| 2 |
> Jason Stubbs wrote: |
| 3 |
> > Only by modifying every ebuild that has a virtual/x11 dependency. The atom |
| 4 |
> > "virtual/x11" cannot be limited to specific versions on its own with old |
| 5 |
> > style virtuals. |
| 6 |
> |
| 7 |
> Is that so? I guess this must be wrong, then: |
| 8 |
> |
| 9 |
> /usr/portage/profiles/base/virtuals:# Only have this for >=pam-0.78, as |
| 10 |
> we want to make use of the 'include' |
| 11 |
> /usr/portage/profiles/base/virtuals:virtual/pam |
| 12 |
> >=sys-libs/pam-0.78 |
| 13 |
|
| 14 |
Yep, portage simply removes the >= and 0.78 parts and makes all versions of |
| 15 |
sys-libs/pam a provider of virtual/pam. Why there is no warning I don't know. |
| 16 |
|
| 17 |
> > The premise for not doing this is that packages will never be fixed, |
| 18 |
> > right? Why not make the modular X provide virtual/x11 and just institute a |
| 19 |
> > policy that no new packages can go into stable with a virtual/x11 |
| 20 |
> > dependency? It could even be easily enforcable if necessary. |
| 21 |
> |
| 22 |
> How does that fix the stale, unmaintained here and upstream apps that |
| 23 |
> are in stable now and have no ~arch ebuilds? |
| 24 |
|
| 25 |
It wouldn't, but at least there'd be fewer packages to deal with in the final |
| 26 |
cleanup. It was just an innocent question though; as far as I can tell, |
| 27 |
emerging any application (ported or not) on a clean system will not break |
| 28 |
even after modular X is unmasked. It's a fine line between whether packages |
| 29 |
"needlessly" not working together due to incompatible (deep) dependencies is |
| 30 |
considered breakage or not though... |
| 31 |
|
| 32 |
/me steps away from the flames for fear of getting burned. |
| 33 |
|
| 34 |
-- |
| 35 |
Jason Stubbs |
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives