| 1 |
On 24 June 2012 05:16, Alec Warner <antarus@g.o> wrote: |
| 2 |
>> |
| 3 |
>> That's covered in the devmanual and in the user documentation, so |
| 4 |
>> there's no need to repeat it here. |
| 5 |
> |
| 6 |
> http://devmanual.gentoo.org/general-concepts/slotting/index.html |
| 7 |
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies |
| 8 |
> |
| 9 |
> I don't think the documentation forbids what these developers are |
| 10 |
> doing. I think you implemented a nice heuristic for your users in your |
| 11 |
> resolver that used to work because slots had a typical set of users |
| 12 |
> cases and the heuristic performed well in those cases. |
| 13 |
> |
| 14 |
> Now people are occasionally using slots in a different way and your |
| 15 |
> heuristic penalizes those cases. That sucks, but you might have to |
| 16 |
> actually change your resolver because I don't think 'funky-slots' |
| 17 |
> properties is going to garner much adoption. It just appears that the |
| 18 |
> heuristic you used to use isn't helpful anymore (or has too any false |
| 19 |
> positives, or whatever.) |
| 20 |
> |
| 21 |
|
| 22 |
|
| 23 |
It seems to me that the defacto understanding of slots is that given 2 |
| 24 |
slots for one package, one slot will be a natural upgrade from another |
| 25 |
competing slot, assuming a slot that is a version progression. |
| 26 |
|
| 27 |
This makes sense for most packages. |
| 28 |
|
| 29 |
However, it seems slots are in some cases being used for purposes |
| 30 |
other than natural version progressions, and representing siblings |
| 31 |
instead of child/parent , and in such case, its not logical to want to |
| 32 |
install a different sibling simply for having a different sibling |
| 33 |
installed. |
| 34 |
|
| 35 |
So the request is to have some sort of metadata to optionally convey |
| 36 |
the intent of what the slot "means", where the defacto method would be |
| 37 |
"They're versions, if X > Y then X is a natural upgrade from Y, and |
| 38 |
is slotted for transition and similar reasons" , which would indicate |
| 39 |
to UA's that if they have Y, and X becomes available, that they will |
| 40 |
want to install X. |
| 41 |
|
| 42 |
And there would be the alternative(s), "Funky slots" , where slots |
| 43 |
DONT indicate version progression, and so should *not* be 'upgraded' |
| 44 |
to from alternative slots. |
| 45 |
|
| 46 |
Logical place to store such information to me seems <metadata.xml> |
| 47 |
|
| 48 |
|
| 49 |
-- |
| 50 |
Kent |
| 51 |
|
| 52 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
| 53 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
| 54 |
|
| 55 |
http://kent-fredric.fox.geek.nz |
Archives