My apologies for the delayed responses. After quite some weeks/months, it's only today that I have managed to set aside a few hours for Belenix.
On Sat, Nov 8, 2008 at 8:41 PM, "C. Bergstr?m" <cbergstrom at netsyncro.com> wrote: > > Hope my first post doesn't create too much of a stir.. We're very consciously open in the Belenix community to new ideas. This is a culture that we've learned from Moinak and others at Sun. Do not worry about controversy, please :) <snip/> > > Building software in a reliable, reproducible way is just as important > as dependency resolution, being able to reliably acquire source and > patch them in a least hassle way can save a lot of time, increase > automation, the quality assurance process and testing. > Indeed ! > (High level overview of problem) <snip/> > Portage which > inherited parts of the ports system extended the idea into distributing > smaller script like files which can reliable build the software and has > a bulit-in mirroring system. While solving the problem of acquiring > sources, patching, and maintaining a package it also introduced > regressions in the QA process either by increased flexibility or lack of > policy as a result. Part of my goal is a 3rd evolution to this process > by reducing the flexibility which is contained in build instructions, > providing a process to work cleanly with upstream and also have the > reliable built-in mirroring system so your nightly build doesn't fail. > I'm interested in learning more about this. What is this mirroring idea that you have in mind ? > > Some key considerations [1] > > * /Storage management/ includes packing and unpacking packages, > checking their integrity, setting up configuration files. > * /Distribution/ is the network transfer of package files. > * /Dependency management/ orchestrates the previous two tasks in > order to install, remove or upgrade software packages while > maintaining the health of the system. > > > Some less considered, but still equally valid points to consider... > > * Reproducibility of build As a person working at Thoughtworks where we practice continuous integration very much (and which I've not yet helped introduce into Belenix), I'd like to hear more from you on this - perhaps in a separate mail to the list. > * Long term package maintenance I have not voiced this concern very much myself, but to me this is a problem that needs to be addressed soon. > * Integrates with upstream This is something that I'm eager to hear how you intend to solve ! > * Quality of existing tools. (Both CLI and GUI) Anything that you have in mind ? I understand that this particular mail is a high level over view and that we can discuss details when we get down to it. > * Speed/perceived performance (network and calculating dependencies) Ack. This perception can affect a distro's image too. > * Build package inheritance (easily creating derived works.. eg > enabling more/less ./configure flags) > * Separation of concern (Between the source and building the source) > * Mirroring capability of binary packages Please expand on this point. <snipping_other_good_points/> > > I had started a big chart comparing the existing tools between ips, > svr4, apt, zypp, portage, pkgcore, ports, sqlports, and conary, but then > realized it would quickly turn from a technical to religious or > opinionated argument than serve as a tool in deciding. > On the Belenix list at least, we're trying to stick to technical merit and don't mind discussing things at ips-discuss itself if need be. So please do not worry about proposing any new ideas. > *Bottom line* > > Problem: > The community needs a way to build source reliably and deliver > binary packages. > > Proposed solution: > 1) Port the smart package manager to solaris > 2) Modify pkgcore to build rpm files compatible with the zypp and smart > 3) Port http://createrepo.baseurl.org/ so we can host binaries > 4) Modify pkgcore to share/update the same installed package > database as smart/zypp > 5) Implement other developer friendly features in pkgcore* > 6) Implement the equivalent of BE (boot environments) into both > smart and pkgcore > Have you started work on any of these ? I'd like to see more :) Also, given that the spec file approach is what we're following at the moment, how does point 2 above tie in with your ideas of better build mechanisms (evolution 3 mentioned above) ? Please elaborate on this. -- Sriram
