Re: [gentoo-dev] Dynamic SLOTs

[Jason Stubbs]

On Saturday 07 August 2004 00:18, Paul de Vrieze wrote:
> 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

The notation used shouldn't have any baring on what is actually being done.

> > 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

But pkg-c may change what's in the installed package tree...

> > 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

The code isn't what needs to be fast. It's the algorithm used that are 
important. I'm not so worried about ARCH-based or KV-based SLOTs any longer 
as I've figured out how they can be handled cleanly without slowing down 
everything else. On the other hand, introducing USE-based SLOTs makes 
everything about a package variable. When atoms can specify any of that 
variation, it becomes horrifically complex.

I, too, am working on a portage-ng. It's called portage. Presently, I'm near 
finishing a new dependency resolver that supports:
* Ranged deps
* USE-based atoms
* SLOT-based atoms
* SLOT upgrades
* Full circular dependency support

Even with all that, a full dependency tree is built with all circular 
dependencies resolved in about 6 seconds, where currently emerge takes about 
2 seconds. I can't see a way to get USE-based SLOTs in without at least 
doubling that figure (which is incidentally the time that 2.0.50 took). I'm 
open to suggestions on how to get around it.

Regards,
Jason Stubbs

--
gentoo-dev@g.o mailing list