1 |
On Wed, Dec 27, 2017 at 05:42:04PM +0200, Mart Raudsepp wrote: |
2 |
> On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote: |
3 |
> > > 2) What you plan to do to have USE=cracklib enabled by default. Two |
4 |
> > > people suggested you should keep this (one way or another) but |
5 |
> > instead |
6 |
> > > everyone is now without it enabled by default. |
7 |
> > |
8 |
> > I plan to do nothing, because I think it should be disabled by |
9 |
> > default |
10 |
> > like all other USE flags. I've CC'ed all of the maintainers who might |
11 |
> > want to add the default to IUSE, and apparently none of them do. The |
12 |
> > hardened project and base-system are also CCed/assigned in case one |
13 |
> > of |
14 |
> > them wanted to adopt the default. |
15 |
> > |
16 |
> > The base profile is the wrong place to enable USE=cracklib, but there |
17 |
> > are better places. If none of the people in charge of those places |
18 |
> > want |
19 |
> > to enable the flag, then maybe it should remain disabled. |
20 |
> |
21 |
> If USE=cracklib is ever removed from base/make.defaults, then this IUSE |
22 |
> default enabling should be done before it is removed for many of the |
23 |
> places where it helps password safety, not afterwards when some |
24 |
> maintainers happen to see you've done it some months later, after we |
25 |
|
26 |
I would say that it is up to you to show where it was approved for |
27 |
adding to base/make.defaults by showing where it was discussed on this |
28 |
list, or showing where it was added in the profile revision history. |
29 |
|
30 |
A bug and that has been open as long as he said it was earlier in this |
31 |
thread, as well as notification here with a 72 hour delay as well as |
32 |
contacting the maintainers directly as far in advance as he did seems |
33 |
reasonable to me. |
34 |
|
35 |
I will look at this more when I get back to my home system, but on the |
36 |
face of it, I would support his change. |
37 |
|
38 |
> |
39 |
> If you need more opposing, then consider this one, as long as this |
40 |
> preparation work isn't done. Just removing it because maintainers |
41 |
> didn't get to it in your timeline isn't something I would see OK. If |
42 |
> you want to make such a base profile change, then I believe you should |
43 |
> contact the maintainers and see which one wants it default disabled, |
44 |
> and which default enabled; do the default enabled changes and only |
45 |
> afterwards you can touch a base default USE flag, otherwise you are |
46 |
> making a change to all these maintainers packages without their |
47 |
> consent. It IS an effective change to their package, and you are |
48 |
> effectively doing non-maintainer changes to them. |
49 |
|
50 |
As he said, he contactedd the maintainers in ample time, so I would say |
51 |
that since they didn't respond he went ahead in good faith. I'll get the |
52 |
link later, but as I recall, the dev manual recommends a 2-4 week wait |
53 |
for maintainers not responding then we can assume that what we are doing |
54 |
is ok. |
55 |
|
56 |
I will look into this more when I get back to my home system, but as a |
57 |
member of base-system, tentavely count me as supporting his change. |
58 |
|
59 |
To respond to the comment about preparation work: |
60 |
Again, I haven't checked the bug, but if it has been there a while and |
61 |
received no input from base-system etc, there may not be any, so |
62 |
removing it from base/make.defaults would be the way to go. |
63 |
|
64 |
William |