Re: Proposal for collaborative maintenance of packages
On Fri, 2005-12-30 at 09:46 +0100, Frank Küster wrote:
> skaller <skaller@users.sourceforge.net> wrote:
> If your upstream software has a good installation procedure - something
> like the autotools
[Lol .. you really don't want to hear my opinion of autotools :]
> type with the possibility to change directory
> locations at configure time (--with-confdir=/etc/foo and such), adding
> or removing files or documentation needs hardly any work of the package
> maintainer. Changed dependencies need just one line in control to be
> edited.
The debian scripts don't use the tarball installation script --
at least I sure hope they don't!!
I have no real idea how to configure the installation
for different user needs on different platforms.
Note the system is doubly cross-compiled: there are actually
four distinct platforms involved in configuring it (the
build, host, target, and run platforms).
For Debian we assume the host, target, and run platforms
are the same .. which still leaves a problem with the fact
the build machine isn't the same.
I have no clear idea how to install it all in general.
Eg .. there are something like 8 distinct kinds of
documentation.. its really hard to know where to put
this stuff.
> So maybe you can use the interaction with Debian to improve your
> program?
Certainly: this has already happened.
For example: some of the documentation is tutorial
examples. But if you try to compile those examples
it will fail if they're in a directory you don't have
permission to write in because the system needs to write
at least the final product right next to the input
script. The upstream system doesn't offer any alternative
at the moment.
This has to be fixed if the examples are to go in /usr/share,
which is where Debian Policy says they should go, but remain
useful. This is a common problem for scripting languages.
I don't have a good solution at the moment. [The best solution
is almost certainly to delegate to a FUSE user space file
system .. but that's fairly adventurous .. :)
> Well, yes. But how's that different to the current procedure - you
> create a package, commit yourself to caring for it, and find a sponsor?
I would be able to press a button, upload the package, press another,
and get back the autobuilder results and lintian/linda scan: all
without hassling my sponsor. I could then ret to fix problems in the
upstream and or packaging .. and go around again. I could also
ask some of the other upstream developers running Debian to try
to install it. When finally it looked clean I could hassle
my sponsor.
As you know sometimes fixes don't work. So I may find
I go around the cycle a couple of times before hassling the
sponsor.. doing that with the sponsor acting as middle man,
it would take longer, and annoy the sponsor because he'd basically
be doing grunt work I could have done. And it annoys me because
it can take 10 times longer with the middleman in the loop.
So perhaps, there could be a small productivity improvement
if I could do some of that myself: not much perhaps but
every bit counts.
If I can risk an analogy -- there are two kinds of 'Accountants':
the book keeper and the consultant. I'd rather the DD act more
as a consultant.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: