1 |
On Mon, 09 Dec 2013 07:57:34 +0800 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
|
4 |
> On 12/09/2013 12:54 AM, Tom Wijsman wrote: |
5 |
> |
6 |
> > Creating a new SLOT is the most sane thing going forward; but, as |
7 |
> > the default (:*) depends on any SLOT, this needs a half thousand |
8 |
> > commits to fix up reverse dependencies. Thus, instead a new package |
9 |
> > is made. [1] |
10 |
> |
11 |
> Pff. Lazy. |
12 |
|
13 |
Yes, but who is lazy here? The person that wants to commit the |
14 |
dependency or the people whom depend on the implicit :* behavior? |
15 |
|
16 |
Or someone else? |
17 |
|
18 |
> > When our defaults force us down such path, that can't be good and it |
19 |
> > affects the quality of our Portage tree; so, this makes me wonder, |
20 |
> > can we change the default from :* to :0? What do you think? |
21 |
> |
22 |
> That just shifts the breakage to other people, who then have to do |
23 |
> more work. |
24 |
|
25 |
Doing a smaller bit of useful work to spare out tons of useless work. |
26 |
|
27 |
As part of a new EAPI it doesn't break. Why do you think so? |
28 |
|
29 |
Why would this yields more work? The dependencies need to be checked |
30 |
anyway as port of version bumps; so, better do them right at once. |
31 |
|
32 |
> > If we agree we do this; in order to change :* to :0, we need to |
33 |
> > change the PMS to cover this change and implement it in the package |
34 |
> > managers. |
35 |
> > |
36 |
> > Before we do that, we need to evaluate how practical this is to |
37 |
> > apply. While we are trying to fix the default behavior, what would |
38 |
> > changing the default from :* to :0 break? |
39 |
> > |
40 |
> > One thing that directly comes to mind is that dependencies that |
41 |
> > have no SLOT="0" ebuild present would need us to manually specify a |
42 |
> > specific SLOT; given that this is a not so common situation, the |
43 |
> > amount of commits needed here is low. |
44 |
> |
45 |
> And now you make updating a lot more fun, because slotted packages |
46 |
> need to be explicitly changed if there's a new slot happening. Just |
47 |
> to hide your own laziness. |
48 |
|
49 |
As per my first question of this reply, whose laziness do you mean? |
50 |
|
51 |
> > Another thing that comes to mind is that we need to check what to do |
52 |
> > with packages were the highest available version does not belong to |
53 |
> > SLOT="0"; technically, restricting these to SLOT="0" will not cause |
54 |
> > breakage, it might however cause some blockers. We'll have to look |
55 |
> > closer into how we can alleviate this result. |
56 |
> |
57 |
> Yup, bad idea. |
58 |
|
59 |
As part of a new EAPI the above is no longer necessary as the change |
60 |
isn't done in place; furthermore, even if we don't do it as part |
61 |
of a new EAPI repoman can cover this with a QA warning. |
62 |
|
63 |
> 500 commits vs. making things more complicated for everyone ... srsly? |
64 |
|
65 |
Why do you think this idea makes things more complicated for everyone? |
66 |
|
67 |
-- |
68 |
With kind regards, |
69 |
|
70 |
Tom Wijsman (TomWij) |
71 |
Gentoo Developer |
72 |
|
73 |
E-mail address : TomWij@g.o |
74 |
GPG Public Key : 6D34E57D |
75 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |