Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Buddha Buck <bmbuck@acsu.buffalo.edu> writes:
> James Troup said:
> > Joey Hess <joey@kitenet.net> 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?
Who said they were bad? They are very rarely necessary however, since
99.5% of the time (the only exception I know of is Hartmut's packages)
i386 packages are already compiled for i386 and don't need to be
compiled by someone other than the maintainer. That's when
binary-only-NMUs occur on non-i386.
> > 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.
Well, duh. [ Actually, if, e.g. postgresql plain lacks m68k support
upstream, that's hardly a bug on the part of the postgresql maintainer
or upstream. Some packages are non-trivial to port and require good
knowledge of the architecture in question. ]
> 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.
Why?
> Portability fixes are the same way.
Again, why?
> What is the procedure for normal NMU's in place to ensure that
> necessary bug-fixes get rolled into the next MU anyway?
Good God, why the hell are you taking part in this discussion, if you
need to ask a question like that?
> > > 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?
Because one includes source and one does not. And because one only
affects one architecture, and one affects all architectures. And
because binary-only NMU's have a distinct and clear purpose aside from
the current issue of fixing bugs in the source which everyone seems
willing to forget[1].
> Aside from Binary-only apparantly current policy?
Ehm, please show me which part of policy binary-only-NMUs break? Stop
the FUD!
> I don't think Joey is anti-non-i386, but that he instead wants
> everyone to play by the same rules.
You don't even know the damn rules, so what the hell are you talking
about? But in case you hadn't noticed "playing by the same rules"
doesn't work, because i386 is not the be all and end all of
architectures.
[...]
> > > 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.
So?
> 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.
Again, so? Both your statements are highly irrelevant to what I said,
please try to stick to the point.
[...]
> > 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.
Rubbish. Read what he wrote:
| > > and your build environment may be non-standard.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| > Eh? Define ``standard'', please? I rather hope you don't mean "what
| > i386 uses".
> 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.
Yes, it's a bug. So what? I know it's a bug. That's why I always
file a _bug_ in the _bug_ tracking system.
> It's not a bug with the m68k version only, it's a bug, plain and
> simple.
Your talent for stating the obvious blows me away.
> 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?
I don't... actually all I want for Debian is more maintainers with a
clue. But I don't think, I'll being seeing too much of that in this
lifetime.
[1] Everyone seems to be forgetting the indisputably valid forms of
binary-NMUs where a simple recompile with no source changes (other
than an entry to debian/changelog) occur. Real life example: some
lamer (i.e. me) compiled bash on an m68k box without ncurses3.0-altdev
installed; end result => libreadline2 linked with libc5 and libc6.
Back when this was hamm, and people were upgrading from pure libc5
systems, this was obviously very very bad. The i386 version didn't
have this problem (nor did the other architectures, because they don't
do libc5-compat, apart from anything else). So I did a
binary-only-NMU of bash, which was a simple recompile on the same box
after installing ncurses3.0-altdev, there were no source changes
except to debian/changelog (to get a different version number). A
normal NMU would have sparked off 100% pointless recompiles on all the
other architectures. I dare someone to claim that that is "NOT ON",
"against current policy", "evil", whatever...
--
James
Reply to: