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

Re: PROPOSAL: one debian list for all porting efforts



apharris@burrito.onshore.com (Adam P. Harris) writes:

> In article <87hfx1iy2b.fsf@garfield.complete.org>, John Goerzen <jgoerzen@complete.org> writes:
> > Martin Mitchell <martin@debian.org> writes:
> >> John Goerzen <jgoerzen@complete.org> writes:
> >> > around compiling all the i386 stuff for the other archs.  But
> >> nobody > goes around compiling the stuff from the other archs for
> >> i386!  So if > I suddenly do all my package development on Alpha,
> >> the Alpha will have > the current versions, and perhaps the Sparc
> >> and m68k too, but i386 > will be obsolete!  Fix anybody?
> >> 
> >> I have been compiling the enscript package for i386, which Hartmut
> >> Koptein maintains on powerpc. So there are people doing this, it
> >> just isn't widespread at the moment.
> 
> > Excellent.  Is there some sort of automated mechanism like the other
> > platforms have?  (That is, packages get automatically build on these
> > other platforms)?
> 
> I believe people use quinn-diff plus dbuild plus god knows ?

[Incidentally, m68k uses debbuild for humans and the build daemons
use something even c00ler.]

Quinn diff can't trivially handle i386, mostly because of binary-only
NMUs, last time I checked.  But since the only actual case of this
phenomenon is still Hartmut (and Martin is, apparently, making his
packages a non-issue), I haven't bothered to think about it very hard.
If it really is a problem nowadays, I could, of course...

[Off the top of my head: enforcing a new numbering policy for bin-only
NMU's (e.g. 3.5-1 -> 3.5-1.0.1 (and not 3.5-1.1)) would solve the
problem and would also solve the problem of bin-only NMU's being
clobbered by source NMU's; I did mean to propose this to debian-policy
several months ago, but apparently I never got round to it]

-- 
James


Reply to: