Duncan wrote: > Steve Long <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, 01 Dec 2006 07:23:09 > +0000: > >> Excellent; pkgcore really sounds great- is there any possibility that >> it'll become the new portage? > > Possibility, yes. It's not certain, as there are multiple contenders > (paludis is the other), and it will be some time, in any case. > > The current problem is that there's no standard definition for what > constitutes an acceptable ebuild, beyond the basic gentoo dev guidelines. > The de facto definition is whatever works with versions of portage > currently in the tree (or just barely removed), but that presents many > difficulties, including both slow upgrades since backward compatibility > must be maintained for longer even when the former functionality is > considered b0rken, and questions of what's broken, the package manager or > the ebuild, when something fails to work as expected. > I'd vote for the defacto with strict backward compatibility, and perhaps a directive/ alias for newer scripts. If something really doesn't work and someone cares (bug reporter), ask them to update the ebuild if needed. So long as good docs are in place (the dev handbook I've seen somewhere is an example) for the update process, that's acceptable in my book.
> Thus, all three package managers, the current portage solution, and > paludis and pkgcore as well, are currently under slower development than > they might otherwise be, while interested parties attempt to hash out a > working standard definition of what actually constitutes a proper ebuild, > and what helper functions said ebuild can in fact depend upon the package > manager to make available. Once that's decided and approved, the playing > field upon which the merits of the next generation package managers can be > judged will be much fairer for all. Of course, with that defined, portage > itself will be freer to progress at speed as well, and it may be that it > will remain the default "approved" solution for quite some time. > As for helper functions, I'd guess a union of all available ;) -- gentoo-dev@gentoo.org mailing list
