[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rawhide report: 20060304 changes



On 3/5/06, Ralf Corsepius <rc040203 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 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.  It's a triage
process at this point.  Ubuntu is still one of the fastest moving
distros, in terms of releasing very current code.  Debian SID has a
lot of the same sort of stuff, but Debian is glacial in creating new
stable releases.  Ubuntu and Fedora both do a great job of pretty
cutting edge stuff out for general users.
The price of pushing out really fresh code is that we must have clear
policies for locking down when a release is due.

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.

       Miles


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]