| 1 |
Duncan wrote: |
| 2 |
|
| 3 |
> Steve Long <slong@××××××××××××××××××.uk> posted |
| 4 |
> ekol7b$q8i$1@×××××××××.org, excerpted below, on Fri, 01 Dec 2006 07:23:09 |
| 5 |
> +0000: |
| 6 |
> |
| 7 |
>> Excellent; pkgcore really sounds great- is there any possibility that |
| 8 |
>> it'll become the new portage? |
| 9 |
> |
| 10 |
> Possibility, yes. It's not certain, as there are multiple contenders |
| 11 |
> (paludis is the other), and it will be some time, in any case. |
| 12 |
> |
| 13 |
> The current problem is that there's no standard definition for what |
| 14 |
> constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines. |
| 15 |
> The de facto definition is whatever works with versions of portage |
| 16 |
> currently in the tree (or just barely removed), but that presents many |
| 17 |
> difficulties, including both slow upgrades since backward compatibility |
| 18 |
> must be maintained for longer even when the former functionality is |
| 19 |
> considered b0rken, and questions of what's broken, the package manager or |
| 20 |
> the ebuild, when something fails to work as expected. |
| 21 |
> |
| 22 |
I'd vote for the defacto with strict backward compatibility, and perhaps a |
| 23 |
directive/ alias for newer scripts. If something really doesn't work and |
| 24 |
someone cares (bug reporter), ask them to update the ebuild if needed. So |
| 25 |
long as good docs are in place (the dev handbook I've seen somewhere is an |
| 26 |
example) for the update process, that's acceptable in my book. |
| 27 |
|
| 28 |
> Thus, all three package managers, the current portage solution, and |
| 29 |
> paludis and pkgcore as well, are currently under slower development than |
| 30 |
> they might otherwise be, while interested parties attempt to hash out a |
| 31 |
> working standard definition of what actually constitutes a proper ebuild, |
| 32 |
> and what helper functions said ebuild can in fact depend upon the package |
| 33 |
> manager to make available. Once that's decided and approved, the playing |
| 34 |
> field upon which the merits of the next generation package managers can be |
| 35 |
> judged will be much fairer for all. Of course, with that defined, portage |
| 36 |
> itself will be freer to progress at speed as well, and it may be that it |
| 37 |
> will remain the default "approved" solution for quite some time. |
| 38 |
> |
| 39 |
As for helper functions, I'd guess a union of all available ;) |
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-dev@g.o mailing list |
Archives