Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, 19 Aug 2003, Brian May wrote:
> Strictly speaking, this is not true.
>
> webmin is buildable by source.
>
> I think even debian/rules works. However, the binary produced by
> debian/rules is very much different to the binary available in the
> archive.
>
> It would appear that the maintainer doesn't understand that you can have
> one source package in Debian generate multiple binary packages.
>
I'm well aware of the concept. However here's the deal: Webmin has a
whole bunch of modules that depend on a wide range of other Debian
packages. So having one binary package would result in a huge list of
dependencies and webmin would take forever to end up in testing and
people would have to install all kind of crap they don't need. Thus the
first thing I did (actually it was a patch from Phil Hands iirc) was to
make each module into a seperate binary package.
This isn't a complete solution. Let us say there is an RC bug in the
wu-ftpd module so it is unable to enter testing. Because the fundamental
unit of the archive is the source package, because of the problem with
that one module, the postfix, LDAP, file upload... etc. etc. won't go in
either.
Now you may say "so what?" Let all the modules go in together when they
are all ready. The thing is the only reason they are distributed together
is for the convienience of the upstream author. In fact there is little
to no logical connection between most of the modules. Inter-release
updates are done on a per-module basis not as a big tarball.
Why should the user of webmin-proftpd be penalized because there is a
problem with webmin-wuftpd? (It is highly unlikely perhaps impossible for
him to have both ftpds installed at once.) But because the fundamental
unit of the archive is the source package, the only way to have seperate
update schedules is to have seperate source packages. An this would have
been necessary in any case because a couple of the modules go in contrib
(as they require java.)
> Hence, the maintainer has written a custom script (read: hack) that will
> split the tar.gz upstream tar ball into one tarball for every package,
> and build each one seperately.
>
> This has two limitations:
>
> 1. seperate source for every package, when it isn't required.
>
I hope I've given you some insight into why it is.
> 2. doesn't build using standard debian/rules build process.
>
Now this I acknowledge is a problem. I am forcing people to go through
extra hoops (albeit modest hoops IMO) to make webmin .debs. One of the
reasons the hack has taken the shape it has is precisely because these
packages are never autobuilt.
At the time I couldn't think of an obvious way to fit what I was doing
into the standard debian/rules framework and frankly I haven't thought a
lot about it since. If you can provide some clues I'd be happy to
implement them.
I suppose one interim thing I could do to lessen confusion is have the
webmin orig.tar.gz contain only the source that makes up the webmin binary
package. But I thought someone somewhere might want to have th tarball as
distributed upstream.
--
Jaldhar H. Vyas <jaldhar@debian.org>
La Salle Debain - http://www.braincells.com/debian/
Reply to: