| 1 |
Roy Bamford wrote: |
| 2 |
> Steve, |
| 3 |
> |
| 4 |
> The offical package manager is portage. If another package manager does |
| 5 |
> something different to portage - even if it fixes a bug in portage, by |
| 6 |
> definition, its not compliant. |
| 7 |
> |
| 8 |
I take it as the spec is what portage is /supposed/ to do, assuming no bugs. |
| 9 |
That's not hard to quantify, since portage normally works pretty well (you |
| 10 |
get an occasional testing release that introduces a bug or regression, |
| 11 |
which is to be expected) and the portage team know what it's supposed to |
| 12 |
do, and are forthcoming to other projects. |
| 13 |
|
| 14 |
The only bug I've found that annoys me, and hasn't been fixed, is the one |
| 15 |
where it doesn't pick up that a blocking package is about to be updated |
| 16 |
before the blockee, so the block will no longer apply. This is easy for a |
| 17 |
user to spot, so it's easy for a script to fix, and we implemented that |
| 18 |
workaround in update months ago. |
| 19 |
|
| 20 |
I'm totally happy with portage and trust its dev team. I know full well that |
| 21 |
2.2 is in the works and have no issue waiting for it to get here, as in the |
| 22 |
meantime portage has worked reliably, as the install base shows. |
| 23 |
|
| 24 |
> The exisiting PMS have been arrived at by documenting what portage |
| 25 |
> does, which is itself a moving target. |
| 26 |
> No PMS is likely to be endorsed until Portage stays still long enough |
| 27 |
> to document it, check it and ratifiy it, unless some arbitary portage |
| 28 |
> version is chosen to document. |
| 29 |
> |
| 30 |
I think we should talk more about EAPI than PMS. That's what ebuild devs |
| 31 |
work to, a BASH api to the most part, with specification of how strings are |
| 32 |
composed and what they mean to the PM. |
| 33 |
|
| 34 |
> Any such PMS won't be very useful, as portage will have moved on |
| 35 |
> meanwhile. A PMS will only be useful when its adopted and maintained by |
| 36 |
> the portage devs, when portage will become a reference inplementaion of |
| 37 |
> the spec. I don't see that happening, since they don't need such a |
| 38 |
> document. |
| 39 |
> |
| 40 |
I agree that the EAPI is not fixed until it's agreed and implemented by |
| 41 |
portage. The PMS thing seems extraneous to Gentoo needs atm; it's more to |
| 42 |
enable other projects to interoperate with the tree. It certainly wasn't |
| 43 |
needed for pkgcore imo. |
| 44 |
|
| 45 |
|
| 46 |
-- |
| 47 |
gentoo-project@g.o mailing list |
Archives