From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 3 Nov 2008 17:23:13 -0800 From: "Roman V. Shaposhnik" In-reply-to: <20081103001543.GC27416@nibiru.local> To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1225761793.4781.213.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1223158526.466.10.camel@ginkgo> <1223351034.19902.17.camel@goose.sun.com> <1224739614.11627.124.camel@goose.sun.com> <20081030180755.GC14902@nibiru.local> <1225401310.32662.34.camel@goose.sun.com> <20081101190557.GB27416@nibiru.local> <2529BB27-520B-432E-9A70-3FB5EE5E938B@sun.com> <20081103001543.GC27416@nibiru.local> Subject: Re: [9fans] plan9port lacks exportfs server Topicbox-Message-UUID: 2eea3160-ead4-11e9-9d60-3106f5b1d025 On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote: > * Roman Shaposhnik 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 > ---------------------------------------------------------------------- >