On Mon, 9 Aug 2010 15:26:12 +0800 Tien-Ren Chen <[email protected]> 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 [1] covering its tree format and package formats, and Exherbo's changes to that format are documented in Exheres for Smarties [2]. 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 > priority): > > * 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 chromium-os-specific EAPI. 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 sanely doable. > * 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 [3] 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 every eclass. > * 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 me slacking...). [1]: http://www.gentoo.org/proj/en/qa/pms.xml [2]: http://exherbo.org/docs/exheres-for-smarties.html [3]: http://tinyurl.com/37fmeuv -- Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ paludis-user mailing list [email protected] http://lists.pioto.org/mailman/listinfo/paludis-user
