James Troup said:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > James Troup wrote:
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
>
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for. If I'm wrong in some drastic way, only m68k suffers.
How does that differ from -any- binary-only NMU, regardless of
architechture? If binary-only NMU's for i386 are bad, why are
binary-only NMUs for m68k OK?
The only -real- problem I see with normal NMUs is that then the i386
and m68k binaries are built from different source packages, and I don't
know if our archiving system has a way of dealing with that.
> You're also forgetting the vast majority of our fixes fall into two
> categories:
>
> 1) Fixing lame packaging bugs.
> 2) Portability fixes.
Both of which, regardless of architecture, are bugs. If there is a
lame packaging bug that prevents easy porting, it should be dealt with
as a bug -- and if that calls for a NMU, then it should be a normal NMU.
Portability fixes are the same way.
> In both cases it's hard for a maintainer to turn round and say, "No,
> your fix is wrong, I wanted the package to be unbuildable from source"
> or "No, get some real hardware, I don't want this package to be
> portable", or "No, that's not the right fix for $ARCH, you should do
> this instead".
Then they probably won't, and if you are lucky, the next Maintainer
Upload will include the changes made for your NMU.
What is the procedure for normal NMU's in place to ensure that
necessary bug-fixes get rolled into the next MU anyway?
> > Binary-only and normal NMU's are the same thing,
>
> No they're not. Why do you insist on this obvious falsehood?
Why are the different? Aside from Binary-only apparantly breaking
current policy?
> [ ... ]
>
> > Do you want the ports to remain forever second class citizens, or do you
> > want them to eventually mature to be equal with i386?
>
> Will you please get off your high horse and stop being so incredibly
> condescending? It doesn't help in anyway whatsoever and without some
> facts to back up your anti-non-i386 rants, it's really rather
> pointless. What exactly makes us second class citizens (your wishes
> aside)?
The only think that I know of that makes ports second-class citizens is
you claiming that because you are different, you should follow
different rules.
I don't think Joey is anti-non-i386, but that he instead wants everyone
to play by the same rules.
> > > All ports needs to make a lot of changes because so many source
> > > packages are broken. It's got little or nothing to do with the
> > > newness of the port (if you look at the {binary-,}NMU's and bug
> > > reports, they aren't predominantly from the new ports, but rather the
> > > older ones (m68k && alpha)).
> >
> > Broken source package has nothing to do with a port at all.
>
> Of course they bloody do; we have to build them. And the breakage I'm
> talking about, is the sort of breakage which doesn't show up for 99.5%
> of i386/source maintainers.
Just because they don't show up most of the time, they are still
broken. And they should be fixed, regardless of if it was found by the
m68k people, the PPC people, the PalmPilot people, or the i386 people.
> > > Eh? Define ``standard'', please? I rather hope you don't mean "what
> > > i386 uses".
> >
> > I mean that we should converge on using the same build environment and build
> > mechanisms (and NMU mechanisms) for all architectures, and until we do, the
> > ports are going to remain second class citizens.
>
> Ehm, so all the architectures using glibc 2.1 are second class
> citizens? If I didn't know better, I'd think you were just using this
> issue as an excuse to vent some anti-non-i386 feelings you seem to
> have.
I think he was referring to Procedures and Policy, not which
compiler/libraries you use.
A source package which doesn't compile out-of-the-box in the standard
Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc
for i386, glibc2.1 plus whatever compiler/libraries/binutils is used
for m86k, and so forth) has a bug -- unless it is specifically
architechture dependent. It's not a bug with the m68k version only,
it's a bug, plain and simple. If it fails on m68k because the
maintainer unconsiously thought that All The World's an i386, then the
source package still needs to be changed -- and Procedures and Policy
should allow that.
I don't think that the non-i386 ports are second-class citizens. I
think that they should be treated as equally, under Procedures and
Policies, as possible. If you claim, as I do, that non-i386 ports
shouldn't be treated as second-class citizens, why do you ask for
special treatment?
>
> --
> James
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
