[gentoo-dev] eclass proposal - savedconfig.eclass

[Daniel Black]

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 <dragonheart@g.o>
Gentoo Foundation