Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes
On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote: Don't like the size of this patch, but it's quite repetitive so... Wouldn't worry on the repetitive, it's repetitive due to the fact the *dbapi classes don't (ab|)use inheritance... * Make all aux_get() functions return a list of strings again Why is this a good thing for EAPI? * Move the EAPI validity check into a separate function * Raise a specific UnsupportedAPIException instead of plain Exception * Mark metadata of unsupported EAPIs as INVALID rather than -1 This doesn't really fly imo. You mark it as invalid, and _no_ portage version (regardless of it's ability to handle that EAPI) will _ever_ regenerate that entry. An old portage version updating the cache would make certain nodes never usable. The -1 is wrong, should be -EAPI. This however is getting back into the eapi should be freeform, not just ints, which I thought I clarified why it should be ints (or people shut up instead of listening to me argue it). :) ~harring pgpF7iBOUVmQH.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes
On Tuesday 04 October 2005 03:30, Brian Harring wrote: On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote: Don't like the size of this patch, but it's quite repetitive so... Wouldn't worry on the repetitive, it's repetitive due to the fact the *dbapi classes don't (ab|)use inheritance... * Make all aux_get() functions return a list of strings again Why is this a good thing for EAPI? Consistency. There is no mapping of names to types so any tool that uses aux_get to enumerate values and assumes that they are strings (as they have always been and still are for every other key) would break. * Move the EAPI validity check into a separate function * Raise a specific UnsupportedAPIException instead of plain Exception No problem with these two? * Mark metadata of unsupported EAPIs as INVALID rather than -1 This doesn't really fly imo. You mark it as invalid, and _no_ portage version (regardless of it's ability to handle that EAPI) will _ever_ regenerate that entry. An old portage version updating the cache would make certain nodes never usable. The -1 is wrong, should be -EAPI. So negative numbers signals invalid cache entries in the scheme? This however is getting back into the eapi should be freeform, not just ints, which I thought I clarified why it should be ints (or people shut up instead of listening to me argue it). :) The only reasoning that I recall without checking is that it wouldn't complicate certain code paths. That's not a valid reason, in my opinion. Can leave that debate alone though. s/INVALID/\-1/ in the patch works for me. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes
On Tue, Oct 04, 2005 at 08:27:09AM +0900, Jason Stubbs wrote: On Tuesday 04 October 2005 03:30, Brian Harring wrote: On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote: Don't like the size of this patch, but it's quite repetitive so... Wouldn't worry on the repetitive, it's repetitive due to the fact the *dbapi classes don't (ab|)use inheritance... * Make all aux_get() functions return a list of strings again Why is this a good thing for EAPI? Consistency. There is no mapping of names to types so any tool that uses aux_get to enumerate values and assumes that they are strings (as they have always been and still are for every other key) would break. What tools are querying EAPI via aux_get already? I'm not much for making it a string purely because everything else is strings. * Move the EAPI validity check into a separate function * Raise a specific UnsupportedAPIException instead of plain Exception No problem with these two? Cleaner, so nope, no complaints. * Mark metadata of unsupported EAPIs as INVALID rather than -1 This doesn't really fly imo. You mark it as invalid, and _no_ portage version (regardless of it's ability to handle that EAPI) will _ever_ regenerate that entry. An old portage version updating the cache would make certain nodes never usable. The -1 is wrong, should be -EAPI. So negative numbers signals invalid cache entries in the scheme? sort of. Indication of what EAPI capable portage is needed that is capable of regenerating that entry correctly. This gets back to why the original patch was doing =0 tests. This however is getting back into the eapi should be freeform, not just ints, which I thought I clarified why it should be ints (or people shut up instead of listening to me argue it). :) The only reasoning that I recall without checking is that it wouldn't complicate certain code paths. That's not a valid reason, in my opinion. Can leave that debate alone though. s/INVALID/\-1/ in the patch works for me. -EAPI... -1 implies 3.x would be capable of regenerating it (may not be the case). It was partially code simplicity, but moreso it's sanity from where I sit. Refinements of specs, packages, projects, whatever, is numerical and increasing to indicate later revisions. EAPI=the horny toad ain't going to happen (nor should it), imo. ~harring pgpMgLIyZgHds.pgp Description: PGP signature
