On Fri, 4 Mar 2011 21:01:30 +0100 "Wulf C. Krueger" <[email protected]> wrote: > * 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.
The Paludis side of this is pretty easy, since it's just a case of saying "don't create manifest entries for exhereses etc". The problem is integrating it into the development workflow in a clean manner. This one's doable without too much C++ knowledge. > * 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. I'm not sure that qualudis was the right way to do it. It was based around the repoman model, which had some fairly severe drawbacks. > * Native support in Paludis for several external repository formats: > - CPAN - Perl modules CPAN's probably impossible since upstream doesn't follow their own spec. > - Ruby Gems gems needs upstream to provide an API for getting 'everything'. The gemcutter query interface didn't support that last time I looked, and although it's theoretically possible to concoct a zillion searches that will eventually find everything, that's obviously not a usable solution in the long term. But if you can get upstream to do that (even if it's something they build once a day and then have us mirror) then this is probably a good project -- and upstream said they'd be willing last time I asked. > * 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. This one's mostly about figuring out how to deal with things that're currently done in pkg_*. > * 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. Lots of refactoring. Not especially difficult, if you're good at writing unit tests first to make sure you don't break stuff. Some others: * interactive mode for 'cave resolve', based upon 'git add -i' * give us a way of creating tar files that doesn't involve libarchive, since libarchive is full of bugs * do something about || dependencies -- Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
