Gentoo Archives: gentoo-portage-dev

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


Subject Author
Re: [gentoo-portage-dev] tree dependency check Brian Harring <ferringb@×××××.com>