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) |