Re: [gentoo-dev] Dynamic SLOTs

[Paul de Vrieze]

On Friday 06 August 2004 14:41, Jason Stubbs wrote:
> On Friday 06 August 2004 20:56, Paul de Vrieze wrote:
> > On Saturday 31 July 2004 08:46, Mike Frysinger wrote:
> > > On Saturday 31 July 2004 12:09 am, Jason Stubbs wrote:
> > > > I added support for USE-based SLOTs to
> > > > support the third and fourth.
> > >
> > > i know this is off topic of your e-mail, but could you go more into
> > > depth on this ?
> > > CHOST / CCHOST / cross compiling dynamic SLOTs interest embedded very
> > > much -mike
> >
> > I'm working on my own portage_ng version. It includes a c++ parser that
> > replaces the bash cruft, is a lot faster, and parses most existing
> > ebuilds. (compilation etc. still happens in bash) (It does not allow at
> > all dynamic behaviour on the toplevel, but it will include a much more
> > flexible dependency structure. On top of that the parser itself does not
> > (yet at least) perform the variable substitution, so the variables are
> > still available for reading. Once I get to that point I will also include
> > some kind of dynamic slot/ multislot feature based on some conditions. It
> > will certainly allow multiple installation of the same version of the
> > same package (think crosscompiling, php for apache1 and apache2) given
> > that they have different MULTISLOT values
>
> Are you going to share information or just offer another sales pitch? For
> example, what algorithm(s) are you going use to handle the following?
>
> pkg-a-1.0:SLOT="foo? ( 2 ) !foo ( 1 )"
> pkg-a-1.1:SLOT="foo? ( 1 ) !foo ( 2 )"
> pkg-b-1.0:DEPEND="foo? ( pkg-a:2 )"
> pkg-c-1.0:DEPEND="pkg-b[foo]"
> USE="-foo" emerge pkg-c

For one thing, I'm going to introduce a prefix based notation (similar to 
lisp) for dependencies, with the current syntax as a shortcut. I'm not yet 
very clear on how the MULTISLOT will work exactly, but variable based 
MULTISLOT should not be any problem

>
> How about if pkg-a is installed in both slot 1 and slot 2 and the user
> issues "emerge -u pkg-a" ?

I have not thought about this yet at all. Probably update both, or give a big 
fat warning/error message

>
> How about if we add pkg-d-1.0:DEPEND="pkg-a[-foo]" and the user issues
> "emerge pkg-c pkg-d" ?

Then we check whether pkg-a[-foo] can be satisfied in the current installed 
tree. If it can it will be (possibly by remerging it), else there is a 
conflict and an error message will be produced

>
> All those have a definite solution, but doing it in code that isn't as slow
> as hell is another matter.

Well, I'll try to work on it with fast code

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net