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

[Pieter Van den Abeele]

On 16 Dec 2003, at 18:11, Sami Näätänen wrote:

> 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 idea of having a deamon maintain a dependency tree is a good idea, 
but somewhat too detailed for a requirement. It doesn't necessarily 
need to be a daemon. It can be a simple standalone program too without 
using a socket or something.

I'd rephrase it as:

A subset (module) of portage is responsible for maintaining a 
representation of the system. We call the representation of a system a 
build plan.
Installing new components can be seen as merging the buildplan for the 
new components with the old build plan.
...

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

modularity is what we want for several reasons

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

I wouldn't call this the portage core, as the existence of this module 
is not -really- crucial for portage to work. In a modular system, one 
should (theoretically, whether this is easy or not is another question) 
be able to communicate with each module, the main module should 
implement things like:

- interaction with the user (a user controls other portage module 
through executing a command like 'emerge --pretend blabla')
- userland modules (interaction with catalyst?) emerge --build-livecd 
asystemspec
...

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

I would use 'knowledge base' instead of database, because it is a more 
generic term. A ports directory is not really a database as we know it 
(think SQL etc.). One of the benefits of formulating the core in 
prolog, would be to use a 'datalog' syntax, datalog is regarded as a 
universal query language. SQL can be expressed in datalog, just like it 
can be expressed in relational algebra/calculus.

Preferences are a good idea, there can be system preferences, user 
preferences ... containing statements about the knowledge base:

avoid pam,
filter unstable packages when the package is a core package
...

I'm also thinking about having regular users specify their own 
preferences, which can be taken into account by root when reasoning 
about the system, but which should be interpreted as wishes instead of 
'requirements'

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

see 2.

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

more generic: 'interprets build plans'

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

I'd add this to 4, The idea is to - just like catalyst - use a strategy 
design pattern:

each concrete architecture/platform can implement its own 
'instal/uninstall' strategy.

> 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 makes eclasses overriding/adding some default behaviour or 
'meta-data' somewhat more difficult to implement.
I'd split ebuilds into two parts: the part detailing 'howto' and the 
part detailing 'about'.

about: dependencies, keywords, use flags (iuse)
howto: command sequences.

howto data can take into account about data, but not the other way 
around. Still, I'd abstract away from the concrete ebuild syntax and 
the way to interpret it. The key is to design a system which is 
powerfull enough to represent other (ports) systems in.

> This way it can be made more secure and easier to control.

right now when you write:

expoit() {
	rm -rf /
}
expoit

at the top of the ebuild, this gets executed when reading data 'about' 
the ebuild. Similarily one could write

DEPEND=""
setdepend() {
	DEPEND=`date`
}
setdepend

which returns another value for DEPEND every time the ebuild is 
interpreted.

I would however allow:

src_compile() {
	sequence of commands
	if (use foo) {
		more commands	
	}
}

because that is really powerfull.


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

I certainly wouldn't exclude using a database (like in sql databases, 
etc.), but wouldn't exclude other possibilities too. If anyone wants to 
create one huge file containing all data in his own syntax, that should 
be possible because of the modular design.

Pieter



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