On 10/12/07, Dermot McCluskey <dermot.mccluskey at sun.com> wrote: > > We are gathering requirements for the next phase of development of > pkgbuild, > the tool we use to build Solaris' GNOME Desktop from RPM-like spec files. > > If there are particular features that you would like to see included, but > are not > listed below, please reply to this thread giving details. Once we have > defined > the requirements, we will be looking for assistance from community members > to implement them. For details on pkgbuild see: > http://pkgbuild.sourceforge.net/ > > Enhancements we are already considering: > - support parallel builds (not just make -j, but building several spec > files in parallel) > - optionally installing to, and resolving dependencies from, a prototype > area > (instead of "/", eg possibly with zones or FUSE-type file > system) > - interactive debugging > - optionally include/exclude source patches from command-line > - spec-file "lint" (eg warn about missing defaults) > - support Solaris 8 & 9 > - better macro support (eg multi-line macros) > - missing RPM features (eg "%if foo == bar") > - "exclude" modifier in %files (eg "%{_libdir}/* %exclude *.a")
1. At the expense of being redundant: Manage recursive dependencies. This sounds easy, but in practice, the tool would need to grok (potentially) thousands of spec files in a directory to see which one provides the dependent package. Assumptions about possible mappings between filenames and packages might help. (SFEfoo.spec could potentially deliver SFEfoo, SFEfoo-devel, SFEfoo-root but never SFEbar) 2. Good documentation - For example figuring out how to build a multi-ISA, multi-platform spec file with package dependencies determined at run time is not really easy. Reading other spec files is currently the way to go - But this will lead to a process where error accumulates over time. 3. A couple of helper tools might come in handy in eliminating some boring manual work a. A script that automatically figures out dependent packages given a binary (or maybe even a python or perl script). I remember seeing some discussions where IPS was supposed to have such capability for ELF and JAR files. If it does, we could reuse it. I have a simple shell script that does a ldd and then does a pkgchk -lp on those libraries to figure out dependencies that I might have missed. But we could probably do better than that. b. A script that will automatically generate the %files section. It could have hard-coded knowledge about common directories and their usual attributes. 4. Something akin to the NetBSD url2pkg that completely automates the creation of simple ports: http://www.netbsd.org/docs/pkgsrc/creating.html 5. In the longer run, something like Debian pbuilder - http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html will simplify the life of SFE contributors. Currently building SFE packages is a trial and error process - there are undocumented dependencies that lie outside the SFE repository which you can figure out only as you go forward building packages and not before you start the first pkgbuild. This apart, there are insufficient dependencies in some of the packages (understandably because a human being writes the spec file). Even more interesting is the phenomenon where SFEfoo is not explicitly dependent on SFEbar but the presence of SFEbar makes SFEfoo alter its runtime behavior. This is quite common for programs written in dynamic scripting languages. Even autoconf's dependency discovery during the configure phase has similar effects. These kinds of emergent properties in the repository can never be figured out unless we have an automated build-system and enough beta-testers. For which, something like pbuilder is very essential. Slightly off topic: How does IPS affect the SFE repository and the pkgbuild tools ? As I understand IPS can import SVR4 packages. But if it has frozen specs for packaging metadata and data, should pkgbuild be enhanced to generate "native" IPS format packages ? I am eager to help out with implementing these or other ideas. Ananth -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20071013/e8c38854/attachment.html>
