Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] tree dependency check
Date: Wed, 29 Mar 2006 22:43:11
In Reply to: Re: [gentoo-portage-dev] tree dependency check by Brian Harring
1 On 3/29/06, Marius Mauch <genone@g.o> wrote:
2 > Marius Mauch schrieb:
3 > > So after manifest2 is in, I'll revive the other issue that IMO is a
4 > > requirement for 2.1: enforcing dependencies needed to use the tree (see
5 > > old threads or glep44 for reasoning). A patch for that is available at
6 > > Unless somebody objects
7 > > I'll add that somewhere next week.
8 >
9 > Ok, from a discussion with Zac and a few others it seems that we should
10 > add a layer of indirection, so instead of specifying atoms the tree has
11 > a freeform version identifier, and portage can use it to look up the
12 > required atoms by using a (remote) mapping file.
13 > This new approach is implemented in
14 > (it's basically a
15 > combination of strategies D and E in d.g.o/~genone/docs/treedeps.txt)
16 >
17 > This new patch also has a few other improvements:
18 > - checks overlays too
19 > - at sync time first check the tree format of the remote tree, if we
20 > can't handle it the sync is aborted
21 > - if no format specification is found warn the user about it (with the
22 > intention to fail in a future version)
23 >
24 > New intended merge date is this weekend or beginning of next week, so if
25 > you have any objections, make them now.
27 In doing compatibility code, should wait a bit to make sure it's sane
28 and that there are no issues _prior_ to deployment- rushing it (3 days
29 notice) kind of conflicts with that requirement ;-)
31 Mind you this is from looking at the code (not running it), so verify
32 it, but here goes...
34 Implementation issues...
36 1) format_check should just return the results (supported, not
37 supported, need xyz) instead of printing to the term. Remember this
38 code may be triggered by gui apps. This also means it shouldn't be
39 abused to check what's been handed in via commandline to know what to
40 exempt, should just return what is required.
42 2) code isn't root aware.
44 3) no snapshot integration.
46 4) code invalidly assumes that all later version of the pulled atom
47 from vdb will work. Format version 1 may not be supported by portage
48 2 years down the line, this code assumes all portage versions from
49 that point on support that format- that is a recipe for bloat/borkage;
50 this is a bit odd of a check/attempt considering the url crap to try
51 and get the appropriate atom.
53 5) Introduced (in the urlopen call) another KeyboardInterrupt
54 swallowing except clause. Don't Do That. :)
56 6) This breaks _all_ syncing for users who have overlays but lack the
57 format versions file. That's a massive no go, you don't break
58 compatibility introducing compatibility checks (nor do you piss off
59 several thousand overlay using users for questionable gain).
61 7) even cooler, say you're running max visible portage, and using an
62 overlay that lacks a format_version file. With the vdb portage
63 lookup, it'll tell the user that they need a version later then the
64 max version. Nice way to get people to test package masked portage's,
65 but it still is wrong.
67 8) (minor) output of todo is going to be fugly if anyone uses actual
68 atom constructs, boolean ORs fex (the print implicitly assumes it's
69 just a list of atoms without any boolean constructs).
71 9) the attempted check to see if a pkg is in the passed in myfiles
72 won't work if myfiles holds atoms; eg,
73 myfiles, pkg = [">=sys-apps/portage-2.0.54"], "sys-apps/portage"
74 assert pkg not in myfiles
76 Perceived design flaws...
78 1) pollution of the rootdir of PORTDIR. To head of the "it's
79 subjective", aside from this repo id will need to be pushed into the
80 tree format also, and any files the tree format version requires
81 *should* be in a subdir. so... basically this single file is going to
82 be sitting in rootdir while all other repository metadata is stuck in
83 a subdir. Seems rather daft to have it shoved in it's own location-
84 compatibility code _does_ have certain hardcoded assumptions for
85 things to work, hardcoding looking in a subdir is no different then
86 hardcoding no subdir (only difference is the subdir keeps things
87 contained/clean).
89 2) It's overengineered. There is _no_ reason to hit up a webserver
90 just to get atoms; that data can be bundled in the tree in a seperate
91 file. As is, this breaks users who sync without a connection without
92 any gain. Realistically, I'd be surprised if any alt package managers
93 go this route (I know I won't be hitting a webserver up for pkgcore).
95 3) What the portage project thinks a repo tree needs does not map to
96 what my tree may need. Clarifying, format 1 specifies portage xyz and
97 bash-3 (ebuilds in the tree use bash regex). My personal tree needs
98 portage xyz (manifest/layout changes), but requires just bash-2. With
99 the central db approach, portage will assume my tree is valid via the
100 version #, and if the number differs, it'll assume that I require
101 bash3 when in reality, my tree is bash-2 and up. This points to why
102 the format -> depends mapping should be bundled with the tree.
104 4) portage-2.0 portage-2.1 are bad names for tree formats. Back to
105 the EAPI int discussion, but I really don't see any gain in string
106 names, regardless the 2.0/2.1 sucks as a descriptive name (subjective
107 I realize) :)
109 Short version- this isn't ready for prime time and (personally) I
110 think it needs to be rethought. At the very least it needs to _not_
111 cause user visible uglyness on enabling the compatibility checks (need
112 a solution for transitioning from unversioned repos to versioned
113 repos). Requiring folks to jam a file with a random string in it in
114 each of their overlays also sucks, ways to make that less sucky would
115 be advisable.
117 Not opposed to the concept, but think this needs a fair amount of use
118 case planning- the bash-3 example folks *will* try jamming in the bash
119 dep fex (spyderous already wants the go ahead for using regex), and
120 while the intention seems to be versioning the tree format, the bash
121 requirement for the tree is also there.
123 So... -1.
124 ~harring
126 --
127 gentoo-portage-dev@g.o mailing list


Subject Author
Re: [gentoo-portage-dev] tree dependency check Marius Mauch <genone@g.o>
Re: [gentoo-portage-dev] tree dependency check Marius Mauch <genone@g.o>