On Wed, 29 Mar 2006 14:42:25 -0800 "Brian Harring" <[EMAIL PROTECTED]> wrote:
> 2) code isn't root aware. If root == $ROOT, then I don't see how it would affect this. Even with $ROOT != / we're using the tools in / for most things, $ROOT is just for deployment. If root means something else here please clarify. > 3) no snapshot integration. Wanted to wait for feedback first before adjusting all tools. > 4) code invalidly assumes that all later version of the pulled atom > from vdb will work. That assumption is only a fallback if not atom mapping for a format can be found. You have a better fallback strategy? > 6) This breaks _all_ syncing for users who have overlays but lack the > format versions file. That's a massive no go, you don't break > compatibility introducing compatibility checks (nor do you piss off > several thousand overlay using users for questionable gain). Reread the code, missing format_version raises a warning, nothing else (for now). > 7) even cooler, say you're running max visible portage, and using an > overlay that lacks a format_version file. With the vdb portage > lookup, it'll tell the user that they need a version later then the > max version. Nice way to get people to test package masked portage's, > but it still is wrong. see above. > 8) (minor) output of todo is going to be fugly if anyone uses actual > atom constructs, boolean ORs fex (the print implicitly assumes it's > just a list of atoms without any boolean constructs). Yeah, if anyone want to take a shot to convert it to feed the list into the depresolver feel free. > 9) the attempted check to see if a pkg is in the passed in myfiles > won't work if myfiles holds atoms; eg, > myfiles, pkg = [">=sys-apps/portage-2.0.54"], "sys-apps/portage" > assert pkg not in myfiles reread the code, we're only comparing the keys (still not perfect, but covers your case). > 2) It's overengineered. There is _no_ reason to hit up a webserver > just to get atoms; that data can be bundled in the tree in a seperate > file. As is, this breaks users who sync without a connection without > any gain. Realistically, I'd be surprised if any alt package managers > go this route (I know I won't be hitting a webserver up for pkgcore). a) it's a fallback if the system and tree don't have a depmap b) it doesn't break c) it doesn't matter what other package managers will do > 3) What the portage project thinks a repo tree needs does not map to > what my tree may need. Clarifying, format 1 specifies portage xyz and > bash-3 (ebuilds in the tree use bash regex). My personal tree needs > portage xyz (manifest/layout changes), but requires just bash-2. With > the central db approach, portage will assume my tree is valid via the > version #, and if the number differs, it'll assume that I require > bash3 when in reality, my tree is bash-2 and up. This points to why > the format -> depends mapping should be bundled with the tree. See above. > 4) portage-2.0 portage-2.1 are bad names for tree formats. Back to > the EAPI int discussion, but I really don't see any gain in string > names, regardless the 2.0/2.1 sucks as a descriptive name (subjective > I realize) :) Well, in the end you need a format->feature map, and these names simply have that mapping implicit in a way. > Requiring folks to jam a file with a random string in it in > each of their overlays also sucks, ways to make that less sucky would > be advisable. s/Requiring/Recommending/ Ideally we could detect if an overlay is local or from a third party, and only perform checks for the latter, but that's not doable atm. Zac: The error-on-missing was your idea, feel free to defend it. Marius -- [email protected] mailing list
