On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
> * 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
> ----------------------------------------------------------------------
>
