| 1 |
> > First and foremost is, will adding this to the tree be used for |
| 2 |
> > function creep, whereby the next request to add to/alter the portage |
| 3 |
> > tree is backed up by "Well, the profile change was already added to the |
| 4 |
> > tree"? I wouldn't want a precedent like this set without the council |
| 5 |
> > reviewing it. |
| 6 |
> |
| 7 |
> I really don't see much of an issue of feature creep. Gentoo/ALT |
| 8 |
> already has a profile. It isn't like there are changes to the actual |
| 9 |
> ebuilds themselves. |
| 10 |
|
| 11 |
Actually there are a lot of packages that need portage to work properly. |
| 12 |
Portage has never been added to DEPEND because portage is expected to "be |
| 13 |
just there". With a paludis profile added how are we gonna deal with that? |
| 14 |
|
| 15 |
- Adding $package to the paludis package.mask? |
| 16 |
- Creating a $packagemanager virtual and expect every packagemanager to |
| 17 |
provide all the functions offered by portage? (E.g. having wrapperscripts for |
| 18 |
several calls.) |
| 19 |
- Make ebuilds that explicit depend on portage depend on portage by adding |
| 20 |
sys-apps/portage to (R)DEPEND? |
| 21 |
|
| 22 |
-- |
| 23 |
Christian Hartmann |
| 24 |
http://www.gentoo.org/~ian/ |
| 25 |
|
| 26 |
PGP Key: |
| 27 |
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865 |
| 28 |
Key fingerprint = 4544 EC0C BAE4 216F 5981 7F95 2154 E5EE 692A 4865 |
| 29 |
|
| 30 |
-- |
| 31 |
gentoo-dev@g.o mailing list |
Archives