* Roman Shaposhnik <[EMAIL PROTECTED]> wrote: Hi,
> >Besides the fact that I'm not making binary packages at all, > >splitted / small sources make packaging a lot easier. > > So let me get this straight: you're trying to solve a problem > that you don't have, right? No, I got a problem to be solved, but it's not to produce general-purpose binary packages. Instead the problem is to produce buildfiles for Gentoo on the one and my own embedded systems builder "Briegel" on the other side. Both have in common that they always work ontop the source (hopefully the upstream's source, but unfortunately often requiring additional patches), while Briegel has some harder constraints, eg. always doing crosscompiling, basing on sysroot (a kind of chroot for from the compiler's perspective), etc. Of course I'm building binary packages, too, but they're always specialized for some particular target system, not general purpose, not comparable to what common binary distros do. Embedded systems tend to have a lot harder constraints than common ws's or servers - what I'm doing is applying embedded constraints to them, too, since I have to face these constraints anyways. It's also a matter of a strict QA, which starts at the source. > IOW, don't ever assume that you can simply take a source > code repository (however well it might be designed) and > produce a product by simply doing ./configure ; make ; > make install ; make pkg. Neither do I, instead I first fix the packages so I can do this. Actually, my Briegel buildsystem works exactly this way: #1: make a fresh sysroot image (eg. install prev. built deps) #2: fetch the source (via the CSDB - source database) #3: uncompress and apply the normalized patch from OSS-QM rep. #4: configure stage (eg. ./configure) #5: build stage (eg. make) #6: install stage (eg. make install) #7: create the binary package (eg. tgz, rpm, whatever ...) Any package that doesn't run cleanly through this process is declared broken and has to be fixed first. Briegel has no room for workarounds, intentionally. > The role of a packager is to address the end-users and thus > add value. The role of a packager (for a specific package) shouldn't be necessary at all. With a properly designed source package, that job can be completely done automatically. Leaving only the role of the distro/system maintainer, who decides things like which packages to get in, where to put certain types of files, some default configs, etc. > The kind of value that project members are simply not interested in. I know, and that tends to be the point where I fork. > >What does prevent you from having lots of separate packages > >in the same SCM ? > > Internal dependencies that are troublesome to externalize > if you break a single source code repository into multiple ones. Which ones exactly (specifically on p9p) ? > Updates of a non-trivial software projects are transactional in nature. The key question for me is: why is the sw so complex at all ? More to the point: what's so complex on p9p ? From what I see, it's structure is quite simple (especially compared with monsters like mozilla), since simplicity is actually one of Plan9's major design goals. > Breaking these transactions apart either by non grouping them > into a changeset, or applying them to different repositories > leads to all sorts of complications, such as inability to use > binary search efficiently for tracking down regressions and > the need for use of broken dynamic linking interfaces to > describe the connections between a single transaction > that spans different repos. Wououow ... binary interfaces ... we're still at the source level, aren't we ? *If* you want to nail down a fixed binary interface, you should to this exactly at that point which defines the interface: the package (eg. library) defining it. In other words: add appropriate regress tests to the library package, not abusing others that just happen to depend on it as regress test. Keyword: design by contract ;-P cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
