Dear All,
Through the below observations I would like to generate a discussion
which I hope will speed up work on the quite complex dependency analysis
issue in T2 I am particularly interested in.
Configuration of a certain package may have an impact on its
dependencies since certain options may refer to external packages,
libraries. For the same reason dependency analysis should be aware
not only of package names, but also the configuration of the packages
planned to be included. Picture could be even more complex if we include
the version numbers, but inside a chosen T2 tree consistency regarding
package version matrix can be assumed sparing so remarkble amount of
time and energy.
In T2 to each package is applied basically one configuration which is
supplemented eventually by settings derived from the selected target's
package matrix. I would call it deductive automatic way of configuration.
It is an excellent approach if the target is mature and one knows exactly
what packages (including dependencies) are needed.
Let us see what benefits may there be if we invert this approach I mean
starting from the conf matrix and solving dynamically the dependencies.
If we allow the package configuration to be splitted (this implies some
changes in the cache file's structure consequently) in optional
sections* [see endnote] (for instance AUTO [this is the actual conf],
COMPLETE, MINIMAL, TYPICAL, CUSTOM1, CUSTOM2, ...) making one
of them the default and make these section/config name enter the
"packages" file as a new field, we can fine tune, reconfigure the target
with minimal efforts evaluating each package's configuration (with relative
dependencies). Evaluation may be done by a script which (standalone,
but called optionally also at the end of the Config script) recursively
iterate through the package configurations appending to the "pkgsel"
file in config/$cfg_name the "X pkg_name" not yet included but needed.
In order to do that we need very accurate dependency infos:
which package(s!) are needed for which package's given conf option;
some dependency may have interchangeable packages, in which case we
need to check whether at least one of them is present if not the first
on the list should be used.
Benefit: we can reduce the target's pkgsel to a couple of key
packages. Example:
X abiword
X audacity
X apache
X lxde/*
if we allow to include conf section
on the same line of pkgsel, we can gain
further flexibility:
X abiword
X audacity typical
X apache complete
X lxde/* minimal
I hope the concept is clear enough for a discussion.
The weak part is the effective dependency list handling I guess.
Maybe someone has better idea on that...
best regards,
helasz
* there is a pure bash readconf function which executes only the
commands line by line of a given section (see below).
So technically this solution may be integrated smoothly into T2.
#!/bin/bash
readconf() {
match=0
while read line; do
# skip comments
[[ ${line:0:1} == "#" ]] && continue
# skip empty lines
[[ -z "$line" ]] && continue
# still no match? lets check again
if [[ $match == 0 ]]; then
# do we have an opening tag ?
if [[ ${line:0:1} == "{" ]]; then
# do we have a match ?
# if array is empty, only $1 and '*' is to be checked
if [ -n "${CONFSECTIONS[0]}" ] ; then
check_matches
else
check_match $1
fi
continue
fi
# found next opening tag after config was read - exit loop
elif [[ ${line:0:1} == "{" && $match == 1 ]]; then
# do we have a match ?
# if array is empty, only $1 and '*' is to be checked
if [ -n "${CONFSECTIONS[0]}" ] ; then
check_matches
else
check_match $1
fi
continue
# got a config line eval it
else
if ! [[ $line =~ ^[\ ]{0,}[\#\;] ]] ;then
if ! [[ $line =~ ^$ ]] ;then
eval "$line"
fi
fi
fi
done < "$CONFIG_FILE"
}
CONFIG_FILE=/path-to-pkg_conf/$pkg_name.conf
# to execute commands in section "typical"
readconf "typical"
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
