On Sat, 2008-05-17 at 23:08 +0200, Pierre Habouzit wrote: > On Sat, May 17, 2008 at 09:01:08PM +0000, Joey Hess wrote: > > What if we just decide that changes made to upstream sources[1] qualify > > as a bug? > > WTF ? What's the point of free software if we invent rules for not > modifying them ?
? AFAICT the point is that we feed those changes back to upstream instead of hoarding them in the current layers of Debian changes. I think it's a good idea. > And well, we're in a bad posture then, because glibc > without patches can't work. And what is it that makes this not a bug in upstream glibc? I know it is a complex build but that only makes it more important that the Debian changes are clear and unambiguous. glibc and gcc are the most complex packages that I regularly build (ok, crossbuild) and I dread seeing the email from incoming that a new version needs to be prepared for Emdebian because it nearly always fails first time, despite working last time. > Striving for minimal differences is good, > but deciding a change is a bug ? please… I think it is right that a change is a bug - after all, Debian builds on a range of architectures that upstream often do not have available. When upstream does not build on these architectures, that is a portability bug upstream. It would catch out someone upstream if they were to try and build the package on that arch so why not post the fix to the upstream bug tracker? Call it a feature enhancement if you like but it still ends up in a bug tracker of one kind or another so might as well call it a bug IMHO. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
