On Wed, Mar 06, 2002 at 04:52:14PM -0600, George Kraft IV wrote:
> > Frankly, I don't believe that you're still wasting our time arguing
> > about this completely trivial matter.
> Trivial or complex, once we published our spec we must scrutinize each and
> every subsequent change request.
Heh. I'd hate to see how the LSB would handle a change that was both
necessary and complex.
> Your 496592 bug report was filed on 12/25/01 and we
> responded on 1/11/02 that we were going to defer it past v1.1.0 so that we
> would have more time to investigate.
It was originally brought to your attention on the 4th of July, 2001, in
http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html
> We did not have enough information nor the
> resources to resolve this particular problem in time for v1.1.0.
You keep claiming not to have enough information, but the only information
you don't have is a good reason for it being the current way. The reason
you don't have that piece of information is that there _is_ no reason
to keep it the way it is.
I don't really see what resources you need. I can loan you a copy of "vi"
if you really need it?
> The gLSB v1.1.1 is not going to happen this week or next, and we have other
> pressing issues which have higher priority.
You know, this is just really troubling to me.
Maybe the problem is that we (Debian and the Free Standards Group)
have a different idea of what the LSB is about. From our perspective,
the LSB's goals are to do nothing more than:
* create a description of the lowest common denominator of
Linux distributions that applications can target
* describe a simple packaging format that supports the essential
things application vendors need (dependencies, postinst
scripts) in a way that can be easily implemented on all Linux
distributions
* tell application vendors how to layout their applications in
such a way that it won't screw over other applications, the
distribution, or site changes
Quite frankly, by that standard, the LSB has already failed. The current
spec violates the above aims by specifying things that vendors don't have
in common (the bin uid), by screwing over the distribution (/etc/init.d
namespace), and by specifying a package format that isn't adequately
easy to use on all distributions (LSB packages can't be automatically
identified).
Doing extra stuff is nice, but not when the underlying point of the LSB
hasn't been achieved. In short, if what you said above is truly the case,
your priorities are seriously flawed.
What should be happening right now (or, preferably, months ago) is this:
* the LSB should be approaching distribution and application
vendors to ensure that the requested change (removing the
bin=uid1 comment) doesn't cause major problems for anyone.
Effectively, that's already been done: there are people from
all those interest groups on this list, and most of them have
already participated in this thread. There haven't been any
concrete ("Application <foo> breaks") problems found. [0]
* the LSB should be going around to all the distribution vendors
(including distributions that have Linux compatability rather
than a Linux kernel, such as the BSDs) and making absolutely
sure that the LSB can be implemented on their platforms, and
making any requested changes a high priority.
* finally, the LSB should be asking themselves what can be done
in future to ensure that distributions can implement their
specs *before* they're released. For example, you should be
requiring approval from representatives of more than just SuSE
(via Dirk Hohndel, Free Software Group board member) before
releasing specs.
> Here is how bin=1 will be resolved. The Written Spec bug 496592 will be
> reviewed by the pending Specification Authority (SA). If accepted, then the SA
> will make changes to the gLSB v1.1.0 errata, the future gLSB v1.1.1, and the
> test suites.
Well, it's nice to see you've got such a thoroughly transparent process,
there. Who's the "pending Specification Authority" ? Is it Stuart Anderson
(the Specification Technical Lead), and if so, he's already agreed [2],
hasn't he? How will I know when it's resolved? Why hasn't it already
been resolved, and what, exactly, is holding it up?
> The only thing that speeds up the process is sufficient information and a
> willingness to participate in the resolution procedure.
I'm not worried so much about speeding it up, I'm more worried about it
*ever* getting resolved. So far there's been absolutely *no* evidence
that anything will be done about it ever.
If this is the way you treat an absolutely trivially fixable issue,
that blocks Debian from implementing the spec, then the LSB quite simply
isn't viable as a process, and we need a new group with the same goal
that actually takes the concerns of distributors into account.
Now, I don't mean to be unfair here: there were a bunch of opportunities
for Debian to review the spec before LSB 1.0 was released that we didn't
take up. The fault is definitely shared. But right now, Debian is trying
quite sincerely to fix this, and the LSB has absolutely refused to do
anything about it for eight months now. Seriously, get it done by the
end of March so we can all move on.
Cheers,
aj
[0] You said something odd in one mail [1] about atd. To quote:
> We have concluded that "daemon" is not required on Debian if atd's
> use of "daemon" gets fixed; however, what about the other
> distributions?
I've no idea what that issue is meant to be, since I don't think it
was raised elsewhere on the list. It's almost certainly not a problem
though, since (a) atd isn't a third-party product, it's included in
all the distributions already anyway; and (b) the Debian package
is also used by the Red Hat folks, so however atd uses "daemon",
it doesn't care whether it's uid 1 or 2.
[1] http://lists.debian.org/lsb-spec/2002/lsb-spec-200203/msg00002.html
[2] http://lists.debian.org/lsb-spec/2002/lsb-spec-200202/msg00053.html
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgpyCTDNJ3ygv.pgp
Description: PGP signature