From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 1 Nov 2008 13:40:43 -0700 From: Roman Shaposhnik In-reply-to: <20081101190557.GB27416@nibiru.local> To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <2529BB27-520B-432E-9A70-3FB5EE5E938B@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII 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> Subject: Re: [9fans] plan9port lacks exportfs server Topicbox-Message-UUID: 2b9118d0-ead4-11e9-9d60-3106f5b1d025 On Nov 1, 2008, at 12:05 PM, Enrico Weigelt wrote: >> I really fail to see what is your problem here. There's no >> rule that source code repository has to correspond 1-1 >> to the binary package. In fact, it is quite common >> to use a single repository for producing a number of >> different binary packages. > > 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? >> One of the biggest mistake an open source distro maintainer >> could make is to assume that his role is trivial. It is not. > > If the source is well designed, it actually *is* trivial ;-p Of course it is not. But then again, I'd rather argue that point with a person who knows first-hand what is involved in a binary packaging exercise. Here's my personal experience working for a company that both produces open source projects and builds commercial products on a foundation of various projects: don't ever assume that projects == products. 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. Most of the time projects exist for other software developers, not end users. The role of a packager is to address the end-users and thus add value. The kind of value that project members are simply not interested in. >> As a software developer, not a user, I do have a different >> set of constraints to optimize for. I would prefer a single >> source repository for plan9port under a reasonable DSCM >> so that I don't have to mix and match bits and pieces by >> hand. > > 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. It is the same reason that makes non-changeset SCMs like CVS so dumb of choice for a source repository. Updates of a non-trivial software projects are transactional in nature. 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. But we've been there before with dynamic linking with you, haven't we? Thanks, Roman.