Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, Aug 20, 2003 at 10:04:40AM -0400, Jaldhar H. Vyas wrote:
> Ok. Lets leave aside for a moment the .debs which would go into contrib
> or non-free so would have to be built seperately. What happens if
> webmin-squid has an RC bug? As Goswin said, all the webmin-* packages
> will be held back from testing. What happens if webmin-squid is ok but
> squid itself is not in testing? (or is removed from testing. This could
> happen if it has an RC bug at freeze time,) Again all the webmin packages
> would be affected. What if webmin-squid has one or two upstream bugfix
> releases in between major webmin versions? Every other webmin module
> would also have to be rebuilt too even though nothing changed.
>
> What you are suggesting was the way things were done before 0.98 and it
> caused all sorts of annoyance for me and the users. I'll make any changes
> necessary to be policy-compliant but I'm firm about the multiple-source
> package thing.
Ok, so when you said "split each module into a seperate binary package."
What you really meant was:
"split each module into a seperate source package."
I gather this is because otherwise webmin would not get into testing
unless each of its binary packages gets into testing, right?
Is this still an issue?
Having lots of source files makes it less convenient to rebuild
for woody.
I am not going to argue this, now I understand your reason.
Is there any reason why webmin and webmin-core need to be seperate
source packages?
Regardless, it should still be possible to have a working
debian/rules for each source package, this just represents
a limitation in your current build script.
Ideally the build script needs to update debian/rules for each
package, or create a script that is called by debian/rules, or ...
Lots of options are available here.
As for the problem with the source file containing non-free code,
if you have prestine source code, this is something that
really needs to get fixed upstream :-(, eg. split into two
files.
--
Brian May <bam@debian.org>
Reply to: