Re: [9fans] plan9port lacks exportfs server

[Enrico Weigelt <weigelt@metux.de>]

* Roman Shaposhnik <rvs@sun.com> 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: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------