1 |
On Fri, 22 Jul 2016 16:41:56 +0300 |
2 |
Andrew Savchenko <bircoph@g.o> wrote: |
3 |
> On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote: |
4 |
> > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko |
5 |
> > <bircoph@g.o> napisał(a): |
6 |
> > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote: |
7 |
> [...] |
8 |
> > >> Few important QA notes: |
9 |
> > >> |
10 |
> > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 |
11 |
> > >> gives false, |
12 |
> > > |
13 |
> > >Thanks, fixed. |
14 |
> > > |
15 |
> > >> 2. REPLACING_VERSIONS can have more than one value, |
16 |
> > > |
17 |
> > >While it can indeed, I see no way for this to happen if package |
18 |
> > >hasn't and never had multiple slots. |
19 |
> > |
20 |
> > Wrong. PMS specifically requests you to account for such a |
21 |
> > possibility. |
22 |
> |
23 |
> Common sence must prevail over formal approaches. While PMS is |
24 |
> great, it is not perfect in all possible aspects, and this one is |
25 |
> one of them. |
26 |
> |
27 |
|
28 |
And this is a perfect example of why so much stuff in Gentoo is subtly |
29 |
broken... Things are usually more complicated than you think, buggy code |
30 |
usually works well enough that the mistakes aren't noticed in most |
31 |
cases, and too many developers are far too convinced of their own |
32 |
competence. You need to appreciate that you do not have a complete |
33 |
understanding of what is going on, your "common sense" is leading you |
34 |
astray, and that that API was designed the way it was out of necessity. |
35 |
|
36 |
> I see no point in trashing ebuilds with dead code that will never |
37 |
> be used. Though if there will be a PMS or eclass function with |
38 |
> "proper" implementation, I don't mind, since extra code will be |
39 |
> moved from ebuild elsewhere. |
40 |
|
41 |
Slots are not the only way in which you can end up with multiple |
42 |
installed versions of the same package. Another way is if there's a |
43 |
fatal error during certain parts of the upgrade process. |
44 |
|
45 |
-- |
46 |
Ciaran McCreesh |