Wulf C. Krueger wrote: > * multibuild: compnerd has a good plan (based on what was discussed in > *that* channel), and a VM on my server but obviously lacks the time to > work on it continuously. Maybe having a student work on it might allow us > to get it implemented and merged as a GSoC project. I also have ideas, but never seem to be on at the same time as compnerd.
> * Native support in Paludis for several external repository formats: > - CPAN - Perl modules > - CTAN - TexLive stuff (TexLive itself is currently being done by Ingmar) > - Ruby Gems CPAN is mostly stalled on ciaranm right now - I've already written a tool that walks all of CPAN and BackPan and generates JSON files with the necessary data for every dist and module. (Modules being a simple pointer to the dist the module is in) > * A sane way for building external kernel modules: Some software has its > own external kernel modules (e. g. VirtualBox, VMWare, nvidia-drivers, > etc.). Currently, we simply install their sources to /usr/src and tell the > user to compile them. We should be able to do better! Might it be possible to just use DKMS? Since there are people working on Systemd for Debian, it'll probably be trivial regardless of initsystem. > * Ability to say "give me a clean config set" without having to > reinstall the package, via paludis --fresh-confs target. This. I LIKE this. > * Ability for packages to handle 'smart' config updates (e.g. if the > package knows you have to change buildroot to builddir). > > * Ability for packages to say "it's ok to overwrite this config file > with our new version automatically if the user hasn't modified it" I'd say it should be a user setting whether to respect such a flag, similar to dispatch-conf. > * Ability for packages to know whether config files were modified. Trivial; Exndbam and VDB already store checksums of installed files, and if it't unchanged, it's what's installed. When the new version installs, if it's unchanged, it's replaced with the new version, *which matches the new version's checksum*, thus preserving the 'checksum matches' property. > * After the merge, if it's a clean install, call pkg_merge_confs with > '-' as $1. Mm, this I'm not so sure of - I tend to port configs from an old install to a new one to save time, *prior* to installing some of the programs the configs are for. I'd rather those not get wiped in that case. > * On uninstall, call pkg_confs_remove. I *strongly* oppose this. Uninstalling and reinstalling has valid uses, and this could erase a user's carefully-edited configuration unless we're *very* careful. > ----------------------- > There're some packages, like dev-perl/autodie, dev-perl/Module-Build, > etc, which exist both as separate packages, and as part of core perl > itself. To make things more confusing, not all versions of perl contain > them. And you can't even just do a simple ">=5.10" for some, since > there's 5.8.9 which came out later. The JSON files solution I have uses Module::CoreList to map core modules (with versions) to the versions of perl they are in core for. _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
