[paludis-user] Contributing patches
ciaran.mccreesh at googlemail.com
Mon Aug 9 08:21:29 UTC 2010
On Mon, 9 Aug 2010 15:26:12 +0800
Tien-Ren Chen <trchen at chromium.org> wrote:
> I am evaulating paludis as a package management system for the
> Chromium OS project.
> There is currently some functionality missing that Chromium OS needs,
> and I was hoping to get some feedback on the paludis community
> interest in these features.
> Specifically, is there a good chance that patches providing these
> features would be accepted?
Our main requirement for additional functionality from package formats
is that it's documented somewhere. For example, Gentoo has PMS 
covering its tree format and package formats, and Exherbo's changes to
that format are documented in Exheres for Smarties . So, if you're
looking for additional features, we'd have to be clear exactly what
they are, and they have to be done in such a way that they only affect
your packages, and not packages following another distribution's EAPIs.
You also need to decide how much Gentoo and Portage compatibility
you're after. Are you aiming to be just "Gentoo plus some extra bits",
or a full blown independent OS? The latter is a lot more work, but the
former severely restricts what you can do.
> The following is the list of features I'll be working on (in order of
> * support package.keywords / package.unmask in profiles
> These 2 files are documented in portage man-pages, but currently no
> repositories is using it except for chromium-overlay.
> I just submitted ticket #954 for package.keywords, and I think
> package.unmask is no harder.
This is an example of something that's not in PMS. Since Portage
already supports it, the options on this one are to convince the
relevant people that the feature *should* be in PMS and that it not
being there is an accident, or to mark your profile as using a
However, you may well be better off just not using package.keywords...
It's a highly weird feature. Alternatively, if you're prepared to kill
Portage and Gentoo compatibility, you may be better doing *everything*
regarding keywording in profiles, but be aware that you'll need to be
hosting your code on Git rather than CVS as Gentoo does to make that
> * binary packages (PBIN?)
> Seems like paludis is actively working on this, but I'm not so sure
> about the current progress. Is there any work that I can help with?
The big remaining problem with pbins is that they need a version of
libarchive which supports archive_write_set_format_gnutar, and there's
not yet a release which includes that, and I believe that their SCM
head breaks something KDEish...
After that, there are a half dozen relatively minor bugs left to tidy
up, then documentation, and then lots of testing to find all the
cross-system oddities that will likely crop up.
The good news is, the new resolver can do some very clever things with
binary packages, so working with them is a lot easier. The old resolver
being icky and not understanding binary packages properly was the main
reason we didn't try very hard to get pbins fully usable before now.
> * parallel compile/install/merge
> Similar to portage-2.2's --jobs option.
We'll never implement that the way Portage does it, since the way
Portage does it likes to break user systems in horrible ways. What we
*will* do is allow multiple binary packages to be built in parallel,
and then installed sequentially.
> * separate host/target dependencies
> As proposed in Gentoo Bugs #201499, to distinguish host/target
> build-time dependencies using label-based dependency.
> Paludis should be able to load two sets of configuration files for
> host/target respectively, determine correct dependency & build order,
> and build packages using the correct environment.
That's something that needs extensive EAPI / package support. The
package manager side of it is easy -- the new resolver already has a
fancy bit of logic  to work out whether packages should be installed
to the / fs, a chroot or a binary package, so it's just a case of
tweaking that slightly. The hard part is getting your packages right,
and in coming up with a package format that doesn't make this a pain in
the ass for developers.
Also, if you go this route, you're probably best scrapping any notion
of Portage support. The DEPENDENCIES + labels format used by exheres-0
would make this a lot easier to handle, but I doubt Portage would be
able to implement that, and it would require support from pretty much
> * smart rebuild for -scm packages
> Add a hook in src_fetch or src_unpack stage, so the ebuild can
> report if the source revision has been changed since last build.
> Also, the scm revision should be included in package metadata, so
> the version of pbin files can be checked against the source code. (and
> rebuild should be done if mismatch)
We have plans for this on Exherbo. Again, it requires support from the
package format (which Exherbo has, so I think this one's just a case of
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the paludis-user