On Fri, 2005-12-30 at 09:46 +0100, Frank Küster wrote: > skaller <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
