RE: Wake Up and Smell the Coffee It's Not 1970!
On Wed, 29 Mar 2000, delau wrote:
> Date: Wed, 29 Mar 2000 01:47:23 +0200
> From: delau <vincent@delau.demon.nl>
> To: lsb-discuss@lists.linuxbase.org
> Subject: RE: Wake Up and Smell the Coffee It's Not 1970!
> Resent-Date: 28 Mar 2000 23:47:29 -0000
> Resent-From: lsb-discuss@lists.linuxbase.org
> Resent-cc: recipient list not shown: ;
>
>
> > Put another way, an LSB that standardizes numerous special
> > cases will be
> > no more concise for simple cases than the status quo (cf. "requires
> > glibc2.1 and FHS 2.0" with "requires LSBbasic1.0a, LSBdns2.1c") and
> > uselessly complicated for the least-common-denominator user (cf.
> > "requires LSB 1.0" and "requires LSBbasic1.0a, LSBx2.0, LSBfoo1.3,
> > LSBbar1.1")
>
> In my original message I used "Bind" as "the (RPM?) package containing the
> BIND dns server" just like any other server should be shipped as a package.
> For the dns server package, the only things I need should be in the "LSB
> Core" subset/profile/layer.
>
Maybe it is me, and i am missing the point. if it is so please, correct
me.
For such application like bind, that are not just for Linux but for
any flavour of Unix, (sendmail, apache, and so), belongs to the developers
decide the structure, taking FHS 2.0 as reference point.
Belongs to LSB to say, ok, because this
packet is a system packet, then the binaries will go in /usr/bin,
and so on. The tgz, rpm, deb, and so on packages should just
respect the structure decided by the developer, and then the location
path from LSB.
For the most of those packets, building them from source, libc 5 glibc
2.0.x or 2.1.0
does not matter indeed.
I have a libc5 server, for example, with apache 2.0 alpha, sendmail 8.10,
bind 9.0 beta2.
Sometimes we have the good tendence to make discussion, and to define
depper and deeper, but on some aspect i know then serious sysadmin
wants a little of freedom.
We should be, and we are de facto, a reference point for linux
distributors, and that is.
on the desktop then users will use configuration tools, and those tools
will make the hard stuff for sysadministration using the path LSB decided,
and respecting the package developers wishes, (configuration file format
and so on).
if a sysadmin is so skilled that he will make everything by hand, then
do you think that libc5 or libc6 is a problem?
(if _NSIG is not defined, for example, he will add in the
sources #define _NSIG 64 and stop!).
That is why i liked the stuff in
http://rob.current.nu/build.
We should define which is our limit.
Luigi Genoni
Reply to: