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

[Sami Näätänen]

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.

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"

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

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?

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

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.

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.

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

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

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.

Because this consept uses database abstaraction we can put only the 
staff that suits well to the database and use other type of data 
structures if more suitable to the needed task.


--
gentoo-portage-dev@g.o mailing list