rawhide report: 20060304 changes

[Ralf Corsepius]

On Sun, 2006-03-05 at 22:01 -0800, Miles Lane wrote:
> On 3/5/06, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > On Sat, 2006-03-04 at 04:20 -0500, Mike A. Harris wrote:
> > > Ralf Corsepius wrote:
> > > > On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
> > > >
> > > >
> > > >>xorg-x11-xbitmaps-1.0.1-3
> > > >>-------------------------
> > > >>* Thu Mar 02 2006 Mike A. Harris <mharris at redhat.com> 1.0.1-3
> > > >>- Made package arch specific due to pkgconfig files being placed in lib64
> > > >>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
> > > >
> > > >
> > > > What?
> > > >
> > > > Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
> > > > instead of libdir:
> > > >
> > > > -pkgconfigdir = $(libdir)/pkgconfig
> > > > +pkgconfigdir = $(datadir)/pkgconfig
> > > >
> > > > That's what other noarch packages do.
> > > >
> > > >
> > > > Alternatively, fix your spec to use
> > > >
> > > > %configure --libdir=%_datadir
> > > > ...
> > > > %_datadir/share/pkgconfig/*.pc
> > >
> > > For now, the important thing is that FC5 is in a state that everything
> > > builds, and is ready for final release.  Minor trivia like this is not
> > > mission critical to the release of the OS.
> > >
> > > Feel free to submit a patch to X.Org to do this, so it is fixed in
> > > the future.
> >
> > It's always great having to experience the "warm feeling" your responses
> > emit and having to experience your attempts on pushing people around,
> > instead of fixing bugs you are responsible for yourself.
> >
> > Even the time you invested to reply my remark exceeds the time it would
> > have taken you to fix your spec-file.
> >
> > Ralf
> 
> Dude, the freeze policy is pretty understandable.
Did you see a formal code freeze announcement? I haven't.

> That said, I do understand that freezes cause frustration.  If you
> look on the linux-kernel mailing list, you'll see the ongoing tension
> between release management and getting patches in.
I am familiar with code freezes and don't argue on their necessity.

But if a bug prevents function after a code freeze, it qualifies as
"release critical"/"must fix" and showstopper.

However, this shouldn't prevent maintainers from providing proper fixes,
and doesn't justify adding semi-cooked, semi-sought-out emergency hacks
into packages.

Ralf