rawhide report: 20060524 changes

[Jeffrey A Law]

On Wed, 2006-05-24 at 19:18 +0200, Tomasz Kłoczko wrote:
> Dnia 24-05-2006, śro o godzinie 12:57 -0400, Matthias Clasen napisał(a):
> > On Wed, 2006-05-24 at 18:55 +0200, Tomasz Kłoczko wrote:
> > > Dnia 24-05-2006, śro o godzinie 12:37 -0400, Bill Nottingham napisał(a):
> > > [..]
> > > > It was linked statically. Static glib libs went away, so....
> > > 
> > > OK. Next round .. why have (literaly) *one* binary (ppp-watch) which
> > > uses now shared libglib must affect glib ?
> > > Is not better rewrite this tool for not use glib ? or what so big
> > > performs ppp-watch where using glib is neccessary ? is it realy so hard
> > > rewrite this for not use glib ?
> > > 
> > > kloczek
> > > PS. remember: fixing some bad things by introduce some way less ass pain
> > > way is *most* worse way of development :>
> > > Better is rest this kind things in current form and add them to TODO
> > > list.
> > > 
> > 
> > What problem do you have with glib in /lib ?
> 
> OK .. let me allow use your way of thinking: why not move more libraries
> from %{_libdir} to /%{_lib} ? :)
> A: because it enlarges minimal boot image (if you do not know RH/Fedora
> are used *directly* in many embeded systems aplyances).
> 
> Correct way of decide case like this is using some siple logic technics
> like by make some sentence false and prove then or not. In this case ..
> can you prove "moving glib to %{_lib} is correct" ?
> Sorry but personaly I don't see real reasons for enlarge minimal boot
> image. Maybe you .. (?)
It seems to me that for these embedded systems that you probably
don't want glib, NetworkManager, etc at all.  So you just don't
include them in your image in any way shape or form.  Thus it
doesn't matter if it's in /lib or /usr/lib.

jeff