part of
fulfilling our vision of Debian as a Universal Operating System, we
intend to continue working both to ensure that Debian is fully
capable of running standards-compliant applications, ant that Debian
remains an excellent platform for developing th
s as policy would be excellent.
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
all init
scripts SHOULD have the same consistent set of functions. I was
thinking that if they are defined clearly in the LSB we might as well
use them. Yet this is a separate policy discussion that's beyond the
scope of the LSB and goes to my personal opinions about
e they do not)?
That's silly, I never said that.
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rams that use kernel-specific ioctls? Are the
> ioctl interfaces defined in the LSB?
This might help. http://www.linuxbase.org/spec/
Cheers,
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
swer my last post in
January. I have read a different interpretation of the LSB
specification than you have. Any comment?
http://lists.debian.org/debian-policy/2002/debian-policy-200201/msg00012.html
With Regards,
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
* Manoj Srivastava <[EMAIL PROTECTED]> [020506 15:47]:
> >>"Grant" == Grant Bowman <[EMAIL PROTECTED]> writes:
> Grant> As I've argued late last year [1] Debian should take the necessary
> Grant> Policy steps to move forward with LSB adoption.
&g
se on a forum
> like debian-project.
Agreed.
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ake the necessary
Policy steps to move forward with LSB adoption. Init scripts [2] are
one point of many related issues. There has not been consensus on this
list. I believe Bdale (based on his platform) feels similarly.
Regards,
--
-- Grant Bowman<[EMAIL PR
orrelated, which is right at the
> other extreme from orthogonality.
Strongly correlated in the general case, yes. Isn't the discussion
about modifying the system to handle the exemptions you describe?
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unreleased
architecture bugs can be handled in a way other than the official BTS.
As crazy as this idea sounds, I think weakening the whole system
definitions for the sake of the unreleased parts is untenable.
Regards,
--
-- Grant Bowman<[EMAIL PROTECTED]&g
n32/cygwin ports already. I'm not aware of
others. I agree with Wichert that this is a somewhat interesting
prospect.
--
-- Grant Bowman<[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
arate- issues. Please see the
"LSB Status" discussion from November, December and January on this list.
This issue is probably the first of many that demonstrates the need for
a clearer understanding of Debian's intent toward LSB. Ignoring it
won't make it go awa
* Miquel van Smoorenburg <[EMAIL PROTECTED]> [020107 14:23]:
> Grant Bowman <[EMAIL PROTECTED]> wrote:
> >* Miquel van Smoorenburg <[EMAIL PROTECTED]> [020107 12:39]:
> >> Grant Bowman <[EMAIL PROTECTED]> wrote:
> >> >* Miquel van Smoorenbur
rious QA areas but this does not preclude work being done by
volunteers in any QA area.
--
-- Grant Bowman <[EMAIL PROTECTED]>
* Miquel van Smoorenburg <[EMAIL PROTECTED]> [020107 12:39]:
> Grant Bowman <[EMAIL PROTECTED]> wrote:
> >* Miquel van Smoorenburg <[EMAIL PROTECTED]> [020106 22:23]:
> >> Yes, but the spec is talking about *.lsb packages, NOT about
> >> *.deb or *
* Miquel van Smoorenburg <[EMAIL PROTECTED]> [020106 22:23]:
> Yes, but the spec is talking about *.lsb packages, NOT about
> *.deb or *.rpm packages. Those don't have to be changed.
Really? I guess that could be. On what basis do you make this
distinction?
--
st source the
file /lib/lsb/init-functions. This file must cause the following shell
script commands to be defined..." There's also a requirement that may
have other ramifications. "...the LSB init.d files themselves should
only depend in /bin/sh features as defined by POSIX.2."
http://www.linuxbase.org/spec/gLSB/gLSB/iniscrptfunc.html
Cheers,
--
-- Grant Bowman <[EMAIL PROTECTED]>
asked on the
`debian-devel' mailing list, or referred to Daniel Quinlan, the FHS
coordinator, at <[EMAIL PROTECTED]>.
The policy, if set explicity, seems to over-ride the FHS. So
technically it could be discussed on debian-policy but there better be a
good reason why you wo
* Anthony Towns [011128 16:06]:
> On Wed, Nov 28, 2001 at 02:11:14AM -0800, Grant Bowman wrote:
> > It seems to me that a natural step would be to update the policy to
> > reflect the FHS 2.2 and add LSB 1.0. Is this already in progress?
>
> I'm not sure if the
a natural step would be to update the policy to
reflect the FHS 2.2 and add LSB 1.0. Is this already in progress?
Forgive me if this is a FAQ.
Cheers,
--
-- Grant Bowman <[EMAIL PROTECTED]>
21 matches
Mail list logo
