Re: [ANNOUNCE] udev 048 release

[Tomasz Kłoczko]

On Wed, 8 Dec 2004, Greg KH wrote:

> On Wed, Dec 08, 2004 at 10:56:27PM +0100, Tomasz K?oczko wrote:
> > First: is it any real reason for use by udev private copy libsysfs which
> > is statically linked with udev ?
>
> Yes, the "system" version of libsysfs is not always the same one that
> udev wants.

Sorry but from eons spend some time on prepare correct build enviromet 
isn't task for each project maintainers but for persons who tries buid 
specified project from source tree :-|

Try prepare in corect form only udev .. and nothing more :_)

Me and probaly many othet people aroud the word who tries build variose
tools for variouse distributions hates maintainers who includes in project 
tree souce code another projects. Much more haten is project maitainer who 
don't allow in easy way use system avalaible libraries.
Please don't try be listed on this long hated maintainers list ;>

Argument allways is like yours .. and allways this is source ass pain
for distribution maintainers like:

- patchin from each new version for use system avalaible libraries if
  something will be changed in build automations (for udev from may this
  year it hapens .. seven times),

- what if in libsysfs will be discovered some nasty bug ? Why I must audit
  not only libsysfs but also any other projests where libsysfs source was
  included ? (this not hipotetycal case .. do you remember case with for
  example with security bugs in zlib ?).

If you want more argumets for not link statisally look at Solarias 10 why 
*ALL* binaries are linked with shared version of any library and lern 
more .. this is _specialy_ for tools very close to kernel layer.

[..]
> > I'm using udev with shared libsysfs for a months and all works correcly.
>
> Great.  Notice any code size savings?  Yeah, it's not really all that
> much.  You also need static linking when using klibc to get a very tiny
> udev for your boot initramfs image.

This not for code saving but for use only one copy of library by any tools 
which uses specifieed API/ABI. In case any bug on for example libsysfs
which can be fixed without changing API/API all what must be performed is
replace libsysfs shared library .. nothing more.

[..]
> > It makes harder packaging udev if someone will try generate udev in
> > for example rpm form with debug info in separated udev-debug package.
>
> I'm sure those who package up rpms of udev have dealt with this properly
> somehow.  For the rest of the world, I'd prefer to keep the current way.

Greg meybe you are very good kernel hacker (for me you are :) but seems 
you are not so good as person for maintaining user space tools ;>

IMO ony ~1-2% of *all* project uses direct stripping chained directly 
chained in build automation which is used by default. All from this ~1-2% 
because maintainer isn't skilled in some subjects.
Default behavior ~99-98% projects build automations is pass not stripped
binaries. On most of this projects (all which uses for example automake)
producing stripped binaries cen be enabled by add -s to linking options
(usualy LDFLAGS="-s").

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@xxxxxxxxxxxxxxxxxx*