Fellow devs, Many packages have far more options than are presented to gentoo users though an ebuild interface. By embracing the principles of choice[1] the gentoo developers have an obligation to provide a far range of choice on their installation. This is particularly important in: - embedded applications - where size matters - secure configuration - minimal feature install to reduce risk caused by zero day vulnerabilities - hardware support - lots of hardware drivers in the same package and a user will only wants one or small number of them - customisation for your hardware - compile time memory guidelines/limits - customisation because, after all, thats why the upstream put it there!
Ebuilds that already have their implementation of savedconfig:
sys-apps/busybox
sys-libs/uclibc
x11-wm/dwm
x11-misc/dmenu
Other potential candidates:
net-misc/dropbear [2]
app-emulation/mol
app-shells/tcsh
dev-libs/klibc
dev-lang/ccc
mail-mta/sendmail
net-dialup/isdn4k-utils
net-im/kadu
net-irc/cyclone
net-wireless/wpa_supplicant
sys-boot/netboot
sys-libs/uclibc++
www-apache/mod_*
net-misc/asterisk
net-misc/zaptel
dev-lang/php
The "savedconfig" configuration control aims:
- provide user with with choices where they make a difference
- provide a single point for configuration editing
- reduce developer effort by supporting every option available without packing
an ebuild full of USE flags
- reduce USE flag bloat where no dependencies are affected
- limit the mass use of USE_EXPAND
The "savedconfig" configuration control does NOT aim to:
- replace the USE flag determination of dependencies
- provide an interface to options where there is only a small number of
options
- replace global USE flags that have ebuild purpose
IMPLEMENTION
In keeping with existing convention /etc/portage/savedconfig seems to be the
logical choice as to where to store configuration. It has CONFIG_PROTECT and
is close to the package.uses files (where other configuration control exists).
INTERFACE:
A user that wishes to customise a particular package will:
1. Emerge the package to obtain the default configuration (I can see how this
could be generally avoided)
2. Edit the saved configuration in /etc/portage/savedconfig/${CATEGORY}/${PF}
3. adds "${CATEGORY}/${P*} savedconfig -*" atom to /etc/portage/package.uses.
(configuration controlling USE flags should be omitted)
4. Reemerge the package
By default packages that have the option of restoring a saved config will,
without specific USE flags or options, store their config.
ECLASS INTERFACES
STORE_CONFIG
store_config -s name1,name2,name3 (file/directory)......
Stores the specific file(s)/directory(ies) in the directory
${D}/etc/portage/savedconfig/${CATEGORY}/${PF}/
If a single file is the only arguement then the file is copied to
${D}/etc/portage/savedconfig/${CATEGORY}/${PF}
store_config should only be called from pkg_preinst or src_install
Also creates the following symlinks to it
/etc/portage/savedconfig/${CATEGORY}/${P}
/etc/portage/savedconfig/${CATEGORY}/${PN}-$(get_version_component_range 1-x)
/etc/portage/savedconfig/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
..
..
/etc/portage/savedconfig/${CATEGORY}/${PN}
As some packages, like uclibc, have regular cross compile functionality which
require separate config files for each host. This can be achieved with the -s
option.
store_config -s ${CTARGET},${CHOST} .config
will copy .config to:
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${P}
and create the following symlinks:
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${P}
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}-$(get_version_component_range
1-x)
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}-$(get_version_component_range
1-x)
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}-$(get_version_component_range
1-(x-1))
..
..
/etc/portage/savedconfig/${CTARGET}/${CATEGORY}/${PN}
/etc/portage/savedconfig/${CHOST}/${CATEGORY}/${PN}
Q1 I'm open to suggestion that all CTARGETS should occur before CHOSTS
Baselevel symlinks, /etc/portage/savedconfig/${CATEGORY}/... can occur if you
specify a empty -s name using an extra comma i.e.
save_config -s ${CTARGET},${CHOST}, .config
RESTORE_CONFIG
restore_config -s name1,name2... (file/directory) ....
Restores the config from the closest match from above (in same order) *IF*
USE=savedconfig.
restore_config should be called in src_unpack or src_compile after any
competing USE flags have been selected.
store_config and restore config should have the same arguements.
[1] http://www.gentoo.org/foundation/en/#doc_chap2
[2] https://bugs.gentoo.org/show_bug.cgi?id=158185
If the -s option is used the config files are restored in the same order
listed in save_config with the -s.
WARN_CONFIG
warn_config (useflags)
warns the user that the useflags have been overridden by savedconfig
Anything else?
Daniel Black <[EMAIL PROTECTED]>
Gentoo Foundation
pgpekacYAqKrP.pgp
Description: PGP signature
