Re: [gentoo-portage-dev] The purpose of USE flags

[Marius Mauch]

On 12/16/03  Sami Näätänen wrote:

> On Monday 15 December 2003 00:23, Marius Mauch wrote:
> > Hi,
> >
> > personally I really dislike this proposal as it adds a lot of
> > complexity for functionality that would rarely be used. Also IMO USE
> > flags should not prevent the installation of a package, that's the
> > job of masking
>
> Well at least in current state masking is very poorly implemented.
> Besides the system I explined can be used as a tree use flags and thus
> it does not make it more complex on teh contrary.

I should have explained better: I'm not against the tree representation
of USE flags, but getting away from binary flags makes things complex.

> Example using current implementation as the functionality basis:
>
> Enable all gui USE 'flags'
> =use.gui.*
> Disable qt USE 'flag'
> -use.gui.qt
>
> So the only thing different is the amount of text and the fact that
> one needs to put multiple rows of stuff. But this is more readable
> than this:
>
> USE="X acpi acpi4linux apache2 avi cdr crypt cups debug doc dvb dvd
> emacs encode esd examples fbcon flash foomaticdb gd gdbm ggi gif
> gphoto2 gpm gps gtk gtk2 imap imlib innodb java joystick jpeg junit
> ladcca lcms leim libg++ libwww lirc mad maildir memlimit mikmod mmx
> mozilla moznocompose moznoirc moznomail mpeg mpi mule ncurses nls oav
> oggvorbis opengl oss pam pdflib perl pic plotutils png postgres python
> qt quicktime readline samba scanner sdl slp sse ssl tcpd tetex tiff
> truetype wmf x86 xml xml2 xmms xv zlib"

These settings don't match, if you want to compare different
implementations please use examples that match. One problem I see with
the tree represenations (and a flag being present in multiple leafs) is
an ordering probem. E.g. we have use.gui.gnome.esd (as esd is part of
gnome) and use.sound.esd. Now a user has "-use.gui.gnome +use.sound", is
esd enabled then or not?

> And besides the USE 'flags' should be program controlled by default
> ala ufed and not in the make.conf.

Why?

> Oh and this representation is simply to make it tree like.
> Because in my opinion all the stuff has to be in database so these
> representations doesn't really matter, does they?

I agree on the tree representation, but I don't agree on the "everything
should be in a database" part. One of the main benefits of a
plain-textfile approach is that it's easy to fix, using databases for
everything adds another layer of complexity.

> So we need a preferences program to set the configurations in the
> database in this way we can controll multiple Gentoo hosts in single
> portage database from single machine.
> Now that I have something up from my final idea I can some what
> clarify the idea.
>
> So we have single database where mutiple hosts information can be
> stored.
>
> We have a portage 'daemon' to handle all the database access, package
> installation and uninstallation. It doesn't need to be allways in the
> background, but it can be launced when something needs it.
>
> This one daemon controlls the dependency tree calculations etc and can
>
> compile multiple packages simultaneysly if all their dependencies are
> allready installed. Thi ofcourse depends wheter the multiple processes
> are allowed or not through SMP and/or distcc and/or openmosix
>
> So now one could que new packages to the daemon at will and it would
> add these to it's dependency tree. The daemon installs new packages to
> the tree (It might even be a special graph, if there are packagages
> that genuinly can depend on eich other) and installs those packages
> that are not meeting the requirements. This way we can also see the
> situations where something can't be installed, because something else
> doesn't work with certain version of the common dependency of the two
> packages.

Now that's a bit more than your original mail ;)

> Now a litle more to the portage level. :)
>
> So the portage daemon would need to be a modular concept to be really
> usefull. So here are my hasty propositions to be as the modules.
>
> 1. Main module, which controls the others. So is kind the current
>    portage core. And the daemon really is only this the others are
>    libraries.

No, the core should do only the initialization of the other modules, and
provide an interface to tools, t should not contain any portage
functionality itself.

> 2. Preferences module. Sets all the system options ie what database
> and
>    the database URI to use etc. This is lot like the current
>    make.profile and some parts of make.conf.

Ok, we can have different config modules, but IMO text configs should be
the default.

> 3. Database handling. This should be so that there can be one for
> every
>    database one might use, but of course not all of them made, but
>    given the possibility to users to make their own. The default
>    should be a very light weigth solution like flat files. This module
>    is responsible for database queries and alterings.

Different modules for portage tree's, package databases and so on, ok.
But we still should use text files as default for several reasons:
- easier to fix
- less dependencies
- current mirror system is based on textfiles, I don't know how
easy/hard it is to get the mirrors switched to a new scheme

> 4. Build module. This builds a package in isolated environment

ok

> 5. Install/uninstall module, which handles the file altering in the
> live system.

ok

> Ebuilds wouldn't anymore be a shell scripts, but the build module will
> offer all necessary commands to build something. Ebuild will simply be
> a command sequence. Same goes for the install module.
> This way it can be made more secure and easier to control.

Yes and no, part of the ebuild-ng format will be shell commands as I
don't see how we can get away from it. Also we'll need a compability
module to parse old-style ebuilds as the current 10000 ebuilds or so
can't be rewritten over night.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.