| 1 |
On 2006.05.16 16:15, Stephen Bennett wrote: |
| 2 |
> If noone has any strong reasonable objections, I'd like to add a |
| 3 |
> Paludis profile to the tree. This would use Paludis as the default |
| 4 |
> provider for virtual/portage (which is a less than ideal name, but |
| 5 |
> that |
| 6 |
> is another discussion entirely), and provide ebuild devs with a place |
| 7 |
> where they can try out some of our profile enhancements should they |
| 8 |
> want to. It is worth noting on the last point that most of these are |
| 9 |
> long-standing Portage feature requests, at least some of which are |
| 10 |
> planned for inclusion in Portage at some point in the future. This |
| 11 |
> would allow devs access to them earlier, as a sort of testbed. |
| 12 |
> |
| 13 |
> The next question is where to put it. The options as I see them are |
| 14 |
> under default-linux/x86/ or in a top-level paludis/ a la hardened, |
| 15 |
> selinux, embedded, and the like. The latter is easier to exclude for |
| 16 |
> those worried about tree size, though the impact there should be |
| 17 |
> minimal. Neither way produces significantly more duplication, since we |
| 18 |
> can make use of multiple profile inheritance. If anyone has any |
| 19 |
> preference or other input, I'd like to hear it. |
| 20 |
> |
| 21 |
> That's my proposal. The benefits I like to think are obvious. The |
| 22 |
> drawbacks are, as far as I can see, in tree size, which should be |
| 23 |
> minimal. Those concerned about local tree size can exclude it, and for |
| 24 |
> size on the mirrors it's trivial compared to the rest of the tree. |
| 25 |
> |
| 26 |
> Comments? |
| 27 |
> -- |
| 28 |
> gentoo-dev@g.o mailing list |
| 29 |
|
| 30 |
Hi all, |
| 31 |
|
| 32 |
Being new to this list and having read every post since just before |
| 33 |
this discussion started, I feel its time for a generic summing up. |
| 34 |
There are a number of interesting questions arising from the thread |
| 35 |
along the lines of |
| 36 |
|
| 37 |
1) Should the Gentoo tree support alternative package managers at all? |
| 38 |
|
| 39 |
2) Should the tree be changed to enable experimental support to be |
| 40 |
added for alternative package managers? |
| 41 |
|
| 42 |
3) Do alternative package managers have to be (at least) backwards |
| 43 |
compatible with Portage? |
| 44 |
|
| 45 |
4) Should Portage be replaced by one (or more) of the alternatives? |
| 46 |
|
| 47 |
I'm deliberately avoiding the use of any names because Portage is the |
| 48 |
incumbent package manager and the questions have only been raised by |
| 49 |
one alternative package manager *so far*. |
| 50 |
|
| 51 |
Question 1) and 2) can be answered in the same breath. If its decided |
| 52 |
that alternative package managers will be supported then any required |
| 53 |
changes to make that possible are inferred, if indeed, its not actually |
| 54 |
possible at the moment. 1) is really a political/policy question, not |
| 55 |
a software engineering question, so should be determined by the council. |
| 56 |
|
| 57 |
3) The answer has to be, as a minimum, alternate package managers need |
| 58 |
to be able to build on what Portage has already installed. That is, be |
| 59 |
backwards compatible. There is no need for users to have an 'undo' |
| 60 |
feature short of a reinstall. Experimental packages are just that, if |
| 61 |
you really might not be able to take the consequences, don't |
| 62 |
experiment. That's no different than for any other package now. |
| 63 |
|
| 64 |
4) This does not even arise until satisfactory answers have been |
| 65 |
obtained to 1) and 2) and any potential Portage replacement has |
| 66 |
undergone a period of testing. However, there has to be a a way of |
| 67 |
migrating the user base to any new package manager should Portage |
| 68 |
become depreciated. Again, just like any other package. |
| 69 |
|
| 70 |
When alternate package manager(s) are proved to safely (no worse than |
| 71 |
portage) do everything from install to maintenance, there may be an |
| 72 |
interim stage where users can choose to install using package manager |
| 73 |
'A' or package manager 'B', knowing that they cannot switch without a |
| 74 |
reinstall. |
| 75 |
|
| 76 |
There is no package in the tree that is sacrosanct - not even Portage. |
| 77 |
Gentoo must evolve (all of it) or die. The process is all self evident, |
| 78 |
its the same process that's followed for every other package in the |
| 79 |
tree. |
| 80 |
|
| 81 |
You probably don't want my views but here they are anyway. |
| 82 |
1) Yes - packages managers are just packages, like every other package. |
| 83 |
|
| 84 |
2) Yes - in a generic way. No special concessions to any particular |
| 85 |
package manager. I know its not like that at the moment because Portage |
| 86 |
defined Gentoo. Looking into the distant future, we can expect Package |
| 87 |
Managers to be replaced like other packages. |
| 88 |
|
| 89 |
3) I'm ambivalent - I'm a user not a dev. |
| 90 |
|
| 91 |
4) Only time will tell. |
| 92 |
|
| 93 |
Regards, |
| 94 |
|
| 95 |
Roy Bamford |
| 96 |
(NeddySeagoon) |
| 97 |
|
| 98 |
-- |
| 99 |
gentoo-dev@g.o mailing list |
Archives