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.
