Gentoo Archives: gentoo-dev

From: Ferris McCormick <fmccor@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] best way to use profiles and package.use.mask?
Date: Tue, 12 Aug 2008 18:59:07
Message-Id: 1218567541.24858.37.camel@liasis.inforead.com
In Reply to: [gentoo-dev] best way to use profiles and package.use.mask? by Steve Dibb
1 On Tue, 2008-08-12 at 12:00 -0600, Steve Dibb wrote:
2 > Okay, this is something that I've wondered about for a while, but need
3 > to ask -- what is the best way (do we even have a policy) for using
4 > package.use.mask in profiles?
5 >
6 > A couple of specific questions:
7 >
8 > If I need to mask a use flag because of use flag dependencies that won't
9 > work on a particular arch, do I need to contact the arch teams to modify
10 > their package.use.mask profile? If the answer is yes, I can see that as
11 > a huge blocker since I'd have to wait on the arches to do something
12 > before I can even put an ebuild in the tree. I realize this is a
13 > per-arch question depending on how each one might respond, but a common
14 > consensus would be good.
15 >
16
17 What happens now is that the ebuild gets added, keywords get dropped as
18 needed, and whoever added the new ebuild opens a rekeywording bug.
19
20 > Are there ever any cases where we could just simply put the use flag as
21 > restricted in the global package.use.mask and then unrestrict them in
22 > the profiles ones if, for example, it only worked on one or a few
23 > arches? Or is the best policy always to mask it on each profile?
24 >
25
26 Personally, I prefer the first. But then, if a package is not going to
27 work someplace, sparc is often one of those places.
28
29 Down side comes if perhaps we are actually testing the package out
30 of /usr/local/portage or some such, and suddenly the use flag for it
31 comes up masked.
32
33 > As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a
34 > dependency (media-video/em8300-libraries) which is only keyworded for
35 > x86, ppc, and amd64. That means I'd have to mask the use flag in alpha,
36 > hppa, ia64, ppc64 and sparc (according to repoman). I could skirt the
37 > issue completely and just run an if statement checking if they are using
38 > any of those three arches, but I'd prefer to do it the right way. And
39 > not piss off any arch teams in the process.
40 >
41 > So I guess my question is, can individual ebuild devs freely edit
42 > package.use.mask files in profiles?
43 >
44
45 Freely? Of course not. We (the arch developers) need to know about
46 it. :)
47 > Steve
48 >
49
50 I see what you are after. I don't see a good answer for your specific
51 request that does not usually involve a bug of some sort, asking the
52 arch teams to look at what you have done or what you want to do. There
53 are edge cases, of course. Like, "I've package.use.masked fast-x86 for
54 bigmath-3.3.3 on sparc because it pulls in the fast-x86 package which is
55 a fast math x86 package written in x86 assembler." But we still want to
56 know what you've done and why, although in a case like that, a ChangeLog
57 entry would likely be enough.
58
59 Speaking for myself and not for all of sparc: If you do what seems best
60 at the time (drop keywords and ask for rekeyword, package.use.mask,
61 use.mask with selective unmasking) and document it, along with just
62 asking on IRC when there is doubt, you won't go far wrong. We might
63 scream at you, but we do that to package developers all the time anyway.
64
65 Default now seems to be to drop keywords and open bugs requesting
66 rekeywording, and that seems to work fine. But unnecessary in edge
67 cases like the one I made up above (and yes, there are some like that).
68
69 And if you know ahead of time you have something like this coming up, as
70 I mentioned before, ask on IRC if you think of it before playing with
71 profiles.
72
73
74 I didn't answer your question. Mostly, I guess, do what seems right and
75 let us know what you did. The best way to do that is through a bug
76 usually. You might not find us on IRC when you need us, and we probably
77 won't read your mail. :)
78
79 Sorry for not helping,
80 Regards,
81 Ferris
82
83 --
84 Ferris McCormick (P44646, MI) <fmccor@g.o>
85 Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

Attachments

File name MIME type
signature.asc application/pgp-signature