Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
"Christopher C. Chimelis" <debian-devel-gw@beezer.med.miami.edu> writes:
> This is true, and this should be fixed, IMO. If "Debian", as an entity,
> is making a decision to become multi-arch supportive, then maybe it's
> time to update the older rules that were made when x86 was the only
> arch, and time to implement some rules and methods that are more
> consistent with multi-architecture development. In short, instead of
> arguing here, let's try to learn to work together on this.
I agree, although I'd like to know exactly what in Policy is
anti-porter, and how, specifically, we can improve the process and the
quality of the ports.
What parts of policy are unfriendly to porters? I will personnally do
my utmost to correct and bugs in Policy, if you could point me to the
actual sections which have the problems.
> Ideally, ALL maintainers would have access to a machine of every arch
> to compile their own packages on it, but I still have a feeling that
> alot of maintainers wouldn't bother compiling their packages on any
> other arch than x86.
I'd love to be able to do this, as an x86 maintainer. Are the
accounts available to x86-maintainers on other boxes? How do x86
maintainers go about getting such an account? I'd be happy to add
this information to the Developer's Reference, if you can give me some
information.
> > Why are the different? Aside from Binary-only apparantly breaking
> > current policy?
Where in policy does it state this? I've seen this claim put forth
many times but I don't see any section of Policy that states this. I
think Policy is broken if it does state this, but I'm sure that's a
controversial claim.
> > 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.
IMHO, Porters do have slightly different rules, because their duties
as packagers are so radically different from the duties of normal
package maintainers. Maintaining a port *is* different from
maintaining just one package for one architecture. We have to realize
this, and allow for it.
> I think that other archs ARE being treated like second-class citizens in
> more regards than just NMUs. I *wish* I had more interest from
> maintainers as to whether their packages compile ok on Alphas or not.
> To date, I've only had three maintainers actually ask me to test build
> their packages on Alphas and run some tests (which they provided)
> to make sure things worked ok. I was more than willing to do this.
> However, on the flip side, I've also received feedback from a couple of
> maintainers that basically said that they don't really care about us.
I'll try to add some stronger wording about porting and why
maintainers *must* care about them if they're going to maintain a
package. We can't force people to care, but if they don't care, maybe
they shouldn't be a Debian maintainer at all?
> In short, if *you* think the current rules are multi-arch-friendly, then
> I might as well stop porting to the Alpha totally. Like it or not,
> other archs have to get some latitude because of the problems that come
> with being on a machine that most maintainers DON'T have access to.
No, but I'd like to know specific steps we can take to fix this.
> Hey, if you really want, I can start dbuild on the master archive and
> just forward all of the build reports to the main maintainers. If it
> doesn't build, it doesn't build. It would then be up to the maintainer
> to fix it a billion times until it passed a dbuild (because most
> maintainers don't know the quirks of other archs), and in the meantime,
> the other arch ports NEVER get released.
>
> Is that a better solution? I hope you don't think it is....
Definately not. Maybe it would be a good idea if we had
source-depends though. AFAIK, the lack of source-depends is one of
the most annoying problems that porters have to deal with. Do you
think we could add an extra field to control files to get this going?
Just so long as it was understood by dbuild, we would be in pretty
good shape to start getting source-depends working. Then we could
require that field by Policy... ?
(Yes, I know this is a complex issue, but I'd like to see interest in
this functionality revived.)
> > 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.
Well, sometimes it requires other programs to be installed, like
debiandoc-sgml. This is not a bug in the package, really.
> > 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 agree. Things need to be changed as to how other archs are dealt
> with -- policy-wise and attitude-wise. I wish I was a billionaire
> that could drop Alphas on the desks of every maintainer in the
> project, but I'm not. I didn't ask to become an Alpha maintainer to
> get as much sh*t as I have gotten about changing things.
Who's given you sh*t ? Ignorant maintainers? Take some names -- lets
embarrass some people who should know better in a public forum, eh?
> > 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?
>
> Because we have special problems that are not easily or feasibly
> addressed by policy. What makes my bugs less important than some
> wishlist item? Believe me, I've seen stuff like that happen (other
> wishlist items closed while my bug-fix patch sits).
Perhaps we should think about making these porting bugs, for the slink
architectures (i386, m68k, alpha), at level Important or higher? Then
the bugs have to be cleared out before we release. Maybe we're too
late to do this for slink, but IMHO a bug which prohbits compilation
for a port should be considered Important or higher. I mean, if we
don't think bugs preventing a package from running on non-x86 is
*important*, then why are we releasing ports as part of Debian?
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
Reply to: