[Exherbo-dev] Google Summer of Code: Ideas

Alex Elsayed eternaleye at gmail.com
Sat Mar 5 16:13:44 GMT 2011


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.




More information about the Exherbo-dev mailing list