Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Kent Fredric <kentfredric@...>
Subject: Re: RFC: PROPERTIES=funky-slots
Date: Sun, 24 Jun 2012 05:34:26 +1200
On 24 June 2012 05:16, Alec Warner <antarus@g.o> wrote:
>>
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies
>
> I don't think the documentation forbids what these developers are
> doing. I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
>
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption. It just appears that the
> heuristic you used to use isn't helpful anymore (or has too any false
> positives, or whatever.)
>


It seems to me that the defacto understanding of slots is that given 2
slots for one package, one slot will be a natural upgrade from another
competing slot, assuming a slot that is a version progression.

This makes sense for most packages.

However, it seems slots are in some cases being used for purposes
other than natural version progressions, and representing siblings
instead of child/parent , and in such case, its not logical to want to
install a different sibling simply for having a different sibling
installed.

So the request is to have some sort of metadata to optionally convey
the intent of what the slot "means", where the defacto method would be
"They're versions,  if X > Y then X is a natural upgrade from Y, and
is slotted for transition and similar reasons" , which would indicate
to UA's that if they have Y, and X becomes available, that they will
want to install X.

And there would be the alternative(s), "Funky slots" , where slots
DONT indicate version progression, and so should *not* be 'upgraded'
to from alternative slots.

Logical place to store such information to me seems <metadata.xml>


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz


References:
RFC: PROPERTIES=funky-slots
-- Ciaran McCreesh
Re: RFC: PROPERTIES=funky-slots
-- Ciaran McCreesh
Re: RFC: PROPERTIES=funky-slots
-- Alec Warner
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC: PROPERTIES=funky-slots
Next by thread:
Re: RFC: PROPERTIES=funky-slots
Previous by date:
Re: RFC: PROPERTIES=funky-slots
Next by date:
Re: RFC: PROPERTIES=funky-slots


Updated Jun 23, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.