> If you have some great project ideas for Google's Summer of Code, *now* > would be a good time to present them here.
You're an amazingly helpful lot. ;-> So far, I got a single answer, you
slackers!
So, here's something for discussion (and, please (!) help me improve the
descriptions):
* DISTFILES checksums/manifests: Since we're using git for our exheres,
patches, etc. we don't really need checksum validation for those but it would
be really nice to have it for DISTFILES. Work out how to do that and imlement
it in Paludis.
* eclectic config is horrible: A decent pluggable configuration management
tool would be really nice. Personally, I like etckeeper but it only covers
keeping /etc in git. Maybe adding Paludis support to manage it would be
possible.
* 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.
* Categories: We want to kill them - still. There are quite a few suggestions
but none have conclusively been verified and, of course, the implementation is
completely missing.
* Revive Qualudis: Yes, our peer-review process is good but it would make our
lives somewhat easier, I think, if we had a good QA tool that could check at
least for the worst problems.
* 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
* A replacement for stages: Now that we have working pbins, this should
"somehow" be possible. I don't really know how (or rather: I've forgotten what
Ciaran said about it ;) ) so this might be a really nice and worthy project.
* 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!
* New profiles implementation: Currently, our profiles can't be altered from
(third-party) repositories. This is especially unfortunate in the case of sub-
options and the like which we have to add to (usually) arbor even though
they're needed in some third-party repository only.
* Killing CONFIG_PROTECT (explanation taken from Ciaran's original mail):
(And whatever we do, it should be git-based!)
-----------------------
...so how's about we make something better?
Functionality I'd like to see:
* Ability to say "give me a clean config set" without having to
reinstall the package, via paludis --fresh-confs target.
* 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"
We'd probably need:
* Somewhere for packages to install a 'clean' config set. Probably a
subdir under the VDB or Exndbam entry.
* Ability for packages to know whether config files were modified.
I'm thinking very roughly along these lines:
* The package manager merges, say, /etc to exndbamid/configs/etc
instead of /etc
* After the merge, if it's a clean install, call pkg_merge_confs with
'-' as $1.
* If it's a version change or reinstall, call pkg_merge_confs with the
old $PV as $1.
* default_pkg_merge_confs copies from SAVEDCONFSDIR to ROOT, using
protection for any overwrites. The DEFAULT_PKG_MERGE_CONFS vars
_REPLACE_IF_UNMODIFIED, _ALWAYS_REPLACE and _NEVER_REPLACE override
this. Or maybe it merges to SAVEDCONFS{PROTECT,REPLACE,DISCARD}DIR,
and the merger does the protection as a second step (DISCARD is purely
visual).
* On uninstall, call pkg_confs_remove.
-----------------------
* CONTAINS/CONTAINED_IN (explanation taken from Pioto's original mail about
it):
-----------------------
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.
So, one solution that has been suggested is to add 2 new metadata keys,
CONTAINS and CONTAINED_IN. They would each be space-separated lists of
packages.
CONTAINS would be for dev-lang/perl, and would look something like:
dev-lang/perl/perl-5.10.1.exheres-0:
...
CONTAINS="dev-perl/Module-Build[=0.340201] ..."
...
# Not sure I like using the [=version] syntax here, but not sure of a
# better one.
Then, we would have a dev-perl/Module-Build like:
dev-perl/Module-Build/Module-Build-0.340201.exheres-0
...
CONTAINED_IN="dev-lang/perl[=5.10.1]"
...
Finally, a package that needs a particular version of Module-Build
would simply dep upon it as if it were just a stand-alone package:
dev-perl/foo/foo-123.exheres-0
DEPENDENCIES="
build:
dev-perl/Module-Build[>=0.340201]
...
"
If perl 5.10.1 is already installed, and 0.340201 is the best available
version of Module-Build around, then nothing will need to be pulled in.
Otherwise, the newest Module-Build would be installed.
-----------------------
* Random stuff:
- Support dying in exlibs in global space properly
- Detect WORK=${WORKBASE}/${PN} and WORK=${WORKBASE} automagically
- Port pkgcore to Exherbo.
- Implement icky-hacks.exlib: [Exherbo-dev] Icky hacks, Message-ID:
<[email protected]>
- Mark EXJOBS readonly somehow, also document it
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
