Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-dev@l.g.o, pms-bugs@g.o
Subject: Re: [gentoo-dev] Re: RFC: extending pkgmove (slotmove) actions to apply transitionally to ebuilds
Date: Sat, 04 Apr 2015 19:41:44
Message-Id: 20150404214118.3dcc223e@pomiot.lan
In Reply to: Re: [gentoo-dev] Re: RFC: extending pkgmove (slotmove) actions to apply transitionally to ebuilds by Ulrich Mueller
1 Dnia 2015-04-04, o godz. 21:36:37
2 Ulrich Mueller <ulm@g.o> napisał(a):
3
4 > >>>>> On Sat, 4 Apr 2015, Michał Górny wrote:
5 >
6 > >> This is not true for slotmoves. The previous slot can be reused by
7 > >> versions not matching the dependency spec of the move. One can even
8 > >> move some versions to a new slot, while leaving others in the old
9 > >> one.
10 > >>
11 > >> For example, you could have app-misc/foo-1:0 and app-misc/foo-2:0
12 > >> and then do the following slotmove:
13 > >>
14 > >> slotmove =app-misc/foo-2* 0 2
15 > >>
16 > >> How would your transparent conversion treat >=app-misc/foo-1:0 in a
17 > >> dependency?
18 >
19 > > As far as I'm concerned, this is a hack and as such it doesn't have to
20 > > cover all the possible cases.
21 >
22 > But in the worst case, your "hack" can cause a broken dependency
23 > graph. On the one hand, above mentioned >=app-misc/foo-1:0 matches
24 > all versions affected by the slotmove, so it should be converted.
25 > On the other hand, it is a perfectly valid dependency specification
26 > which could have been added after the slotmove, in which case it
27 > shouldn't be converted. You cannot know here what the intentions of
28 > the developer are.
29
30 But it *will* be converted in vdb the next time updates are applied.
31
32 --
33 Best regards,
34 Michał Górny

Replies