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

[Sami Näätänen]

On Tuesday 16 December 2003 21:59, Marius Mauch wrote:
> On 12/16/03  Sami Näätänen wrote:
> >
> > 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.

And things that doesn't well fit in binary world will be complex if 
represented in binary. So that's why I would see that makeing something
that looks like binary, but can get other values if explicitly added 
would be best choice.

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

I think this is problem only if the thing is graph. What it is if the 
flags can be present in many places.

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

Because even at current state these flags are not very self explanatory 
and thus can make a really big mess to control. I although agree that I 
am a fan of config files, but only to the point where they are clean an 
ordered, what the whole punch of use flags simply are not.

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

I would keep a flat file backup, which then could be parsed to the 
database. This gives the speed and reliability.
So one file for the system one for the package tree etc.

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

Yeah sorry that one was just part of my portage dream... :)

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

That I meant. the core was simply a bad choice of word.

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

Well I meant more like we could only upgrade this part to suit the needs
of possible new modules withouth breaking all the other stuff.
and besides I definitely want to use text config files for this.

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

The current sync would be a portage daemon connecting to another one.
The way to do it could be simply rsyncing the tree 'backup' and then 
localy parsing it and making the changes. The only problem is how to 
make package name/category transitions easily, but that could be made 
say using package identifiers instead their names as the basis of the 
package then package transformation would be a simple field change. 
using say 64 bit integer will give quite many possible packages. :)

Default database would be some custom made 'database' using flat files 
or similar. The alternatives that I would include to the core portage 
teams shoulders would be berkely DB, postgresgl and mysql.

And I would make the flatfile backup system, which could be made when 
syncing or after bunch of (un)installations. Ofcourse also when asked 
to backup the system.
 
> > 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.

I would put all the stuff to database like this.

All dependency and fetching etc info from the ebuilds to database 
fields.

All the building, installation etc functions to database so that every 
needed function could be a either shell command sequence from the 
current ebuilds or a new command sequence. These new command sequences 
can be interpreted differently to make the process more secure and 
possibly faster.

These old-style ebuilds can be parsed to the database. After all we 
would need a way to make new ebuilds and for that flat file is the 
simple and efective solution. So we would need to be able to parse 
theese things to the database any way.

One more bonus is that we can put some default command sequences to the 
database and if those are enough to the package then use one of them. 
If not write new one.


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