Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: Re: recommended USE flags
Date: Sun, 13 Aug 2006 10:23:45
Message-Id: ebmucm$p3m$2@sea.gmane.org
In Reply to: Re: [gentoo-amd64] Re: Re: recommended USE flags by "Hemmann
1 "Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
2 200608122218.22034.volker.armin.hemmann@××××××××××××.de, excerpted below,
3 on Sat, 12 Aug 2006 22:18:21 +0200:
4
5 > On Saturday 12 August 2006 20:35, Duncan wrote:
6 >> Peter Humphrey <prh@××××××××××.uk> posted
7 >> 200608121835.43684.prh@××××××××××.uk, excerpted below, on Sat, 12 Aug
8 >>
9 >> > I disagree. It's easy enough for use.desc to say "This will pull in the
10 >> > whole X-Window System" or "Enables programs to handle WMF files". Or even
11 >> > just to include a single-letter G or L prefix to each description as a
12 >> > first step.
13 >>
14 >> But the thing is, different packages may do different things with a USE
15 >> flag. Support for X is often linking against xlib (as in the example I
16 >> gave), but doesn't have to be that major, and (again as in the example)
17 >> could be a minor as adding a few icons and *.desktop files. The only way
18 >> to describe the effect of a USE flag on each package, in many cases, is to
19 >> do just that, make the description per package, not global.
20 >
21 > so instead of a short but useful hint, which is enough in 95% of cases,
22 > concentrated in two files, you want the user to search all packages and read
23 > thousands of descriptions just to figure out if he wants the flag or not?
24 >
25 > Are you insane?
26
27 Well, maybe =8^P, but I don't seem to be conveying what I'm trying to say
28 accurately. No, I'm NOT saying search all packages and read thousands of
29 descriptions (and agree, that could be considered insane, tho it's more or
30 less what one has to do now)...
31
32 > Oh, and for local-flags, there are several descriptions, have a look at ufed.
33 > For the global ones 'pulls in X' or 'needed for mp3/wmv/avi support' is
34 > really enough to know.It does not matter, that the single package does. I
35 > want them to have wmv/mp3/X support, how they are do it, is the ebuild's
36 > problem, not mine. I set a flag, the ebuild maintainer has to figure out how
37 > to react to it.
38
39 What I'm suggesting is that use.desc stay more or less as it is, with a
40 general description for global USE flags. However, instead of
41 use.local.desc only having non-global USE flags, have it list all flags
42 (or split it into two or more files if it gets unmanageably huge) for all
43 packages, with what they do for that package.
44
45 For a quick idea of what the USE flag does in general, then, if it's a
46 global USE flag, one would check the entry in use.desc which would be
47 much as it is now. For a better idea of what it does in a particular
48 package, check the corresponding entry in use.local.desc, which would
49 describe the effects of the flag on that particular package. That's what
50 I'm proposing. Users could just check the general description if that's
51 all they wanted/needed, and have exactly the same level of info they have
52 now, with a possible tweak to a description here or there. If they wanted
53 to know for example what the gnome flag did in the pan package, however,
54 they'd look in use.local.desc and see something to the effect of "Builds
55 against libgnome to let pan use the configured gnome browser."
56
57 See, the problem is that a flag, while it generally adds support for
58 <flagfeature>, can mean very different things in different ebuilds. An
59 example is the perl flag. In some ebuilds, it means build perl bindings.
60 In others, it means install documentation for use with perl. In still
61 others, it controls building optional package documentation that requires
62 perl to build -- documentation for the package, not for using it with
63 perl, but requiring perl to build that documentation. Those are three
64 VERY different meanings, applying to different packages, with USE=perl
65 used to control them. Having a per-package entry would allow the user to
66 see precisely which of these the perl flag was used for in a particular
67 package, or if it was used for something else entirely. There's simply no
68 way to convey that with a global description, unless you effectively
69 include the per-package descriptions right in the global description, of
70 course making it long enough to do so, which would then leave us without a
71 way to get a short and concise general description whet that's all that's
72 needed.
73
74 Still think it's insane, or did I actually convey the idea in a way that
75 makes a bit more sense, now (whether you agree with it or not)? =8^)
76
77 --
78 Duncan - List replies preferred. No HTML msgs.
79 "Every nonfree program has a lord, a master --
80 and if you use the program, he is your master." Richard Stallman
81
82 --
83 gentoo-amd64@g.o mailing list

Replies