| 1 |
Seemant Kulleen wrote: |
| 2 |
> So I think the question that |
| 3 |
> we need to answer is *what* changes are necessary to the profiles and |
| 4 |
> *why* -- or I suppose, why would paludis/pkgcore need to have its own |
| 5 |
> profile? |
| 6 |
|
| 7 |
The profile currently being proposed would change the default |
| 8 |
virtual/portage provider, and ensure that paludis gets pulled in instead |
| 9 |
of Portage in the system set. It would also serve as a proving ground, |
| 10 |
if you will, for some profile features that Paludis supports and Portage |
| 11 |
does not -- for example, profile level USE forcing (for example, the |
| 12 |
ip28 USE flag in relevant Mips profiles), USE combination restrictions |
| 13 |
(see the PHP ebuilds for where this could be useful), and potentially |
| 14 |
multiple profile inheritance. According to my understanding of Portage's |
| 15 |
profile handling, these will all be silently ignored by Portage, so |
| 16 |
nothing will break. Paludis' profile handling is, as far as I know, |
| 17 |
fully backwards compatible; the new profile is purely for the change in |
| 18 |
the system set and to provide a place where people can use the new |
| 19 |
features without stepping on anyone else's toes. |
| 20 |
-- |
| 21 |
gentoo-qa@g.o mailing list |
Archives