Re: Delegation for trademark negotiatons with the DCCA
Steve Langasek writes...
> Did you happen to see the comments about getting a sane option for init
> script handling into the LSB, so that we don't get stuck having to argue
> with LANANA at some later date?:
> http://lists.debian.org/debian-project/2005/09/msg00224.html
Yes, I did.
As you pointed out, we make no claims that our packages providing init scripts
are LSB compliant. While we do still share the namespace in that directory and
collisions are possible, it is generally understood that the LSB runtime
implementor (read: us) owns the majority of that namespace and that if 3rd
party providers want to avoid collisions they will use either the provider DNS
method ("foo.com-bar") or register an lsb based name with LANANA ("lsb-foo").
For example:
* Debian delivers the apache web server with an init script named "apache"
* the Apache project ships an LSB package of their web server, they would
probably register "lsb-apache" with LANANA or if they didn't want to go to the
hassle use "apache.org-apache".
* a 3rd party developer wants to provide a custom version of apache as part of
their product, they would use "foo.com-apache"
All 3 could coexist.
Sometimes I wonder if /opt should have it's own init space too.
> Er, surely it's a much larger change than just adding the new linker hack --
> it also requires adding in forked copies of several libraries.
I was making a distinction between "change" and "addition". The extra libs are
in new packages and install in locations that don't affect the primary copies
or the rest of the system.
> It's ultimately Joey's call, but I think it would be far preferable to
> try to fix these lapses in the core libs instead of shipping two
> copies of libc and libpam with sarge r1.
Well fixing the core would definitely violate the stable release criteria
since it changes the ABIs. (at least that's my understanding, Jeff can confirm)
--
Matt Taggart
taggart@debian.org
Reply to: