[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upstream debian/ dir.



On Fri, Feb 14, 2003 at 07:40:31PM -0500, John Belmonte wrote:
> It turned out he agreed to omit the debian tree from his tarballs at my 
> request, but I also suggested he could just rename the directory to 
> debian_sample.  In this way there would be no interference with my work, 
> and he could keep debian_sample loosely synchronized as he saw fit.

i don't see the need for this seperation.
it suggests that debian maintainer and upstream should not work in
unison, but keep their work seperate. why is that?

in an ideal situation upstream would be built in such a way that there
are no debian specific patches necessary. fixes found by debian users
could and should be included in the upstream code anyways. usefull
seperation of code, to make use of existing library packages, or changes
for fhs compliancy are good for upstream too.

the only real difference would be the build process where upstream may
have to go through hoops and jumps to satisfy dependencies while the
debian build process is much simpler because locations of dependant
things are known.

the debian maintainer could be seen as part of the upstream team,
only being responsible for the debian build part of it just like the
rest of the upstream team, where different people may be responsible for
different parts.

that approach would avoid some of the flamewars between upstream and
debian maintainers, that we have seen in the past...

ideally debian packages and all other form of release (rpm, tarball)
would be done at the same time. with debian maintainer and the rest
working together, a complete release in all package variants could be
done at once, and lessen the headache for all, when it comes to handling
the bugreports for different versions of a package...

i don't like to get told by upstream to forget the debian package and use the
tarball, because the debian maintainer doesn't keep up. that should not
be necessary.

if upstream is inviting to put the debian/ tree in their cvs, then they
are showing a will to cooperate that should be taken advantage of.
getting upstream to understand and cooperate with debian issues should
actually make the work of the debian maintainer easier,
and then, the debian/ tree woudln't really risk getting out of sync with
the rest.

greetings, martin.
-- 
interested in doing pike programming, sTeam/caudium/pike/roxen training,      
sTeam/caudium/roxen and/or unix system administration anywhere in the world.
--
pike programmer     working in europe                             csl-gmbh.net
                    open-steam.org     (www.archlab|(www|db).hb2).tuwien.ac.at
unix                bahai.or.at                       iaeste.(tuwien.ac|or).at
systemadministrator (stuts|black.linux-m68k).org        is.(schon.org|root.at)
Martin Bähr         http://www.iaeste.or.at/~mbaehr/



Reply to: