On Thu, Aug 29, 2002 at 06:57:38PM -0500, Chris Lawrence wrote:
> > It had been my
> > understanding that our init system and/or runlevels were an issue as
> > well; is that a part of the spec we don't have to comply with for the
> > specific certification we are seeking?
> [The] 1.2 spec [clarif
On Aug 29, Branden Robinson wrote:
> On Thu, Aug 29, 2002 at 08:24:25AM +1000, Anthony Towns wrote:
> > Debian 3.0r0 (woody), is close, but not quite, in compliance with LSB 1.2.
> > The outstanding issues are:
> [snip]
>
> Thanks for this extremely informative report. It had been my
> understand
On Thu, Aug 29, 2002 at 08:24:25AM +1000, Anthony Towns wrote:
> Debian 3.0r0 (woody), is close, but not quite, in compliance with LSB 1.2.
> The outstanding issues are:
[snip]
Thanks for this extremely informative report. It had been my
understanding that our init system and/or runlevels were an
On Thu, Aug 15, 2002 at 07:37:10AM -0700, Grant Bowman wrote:
> What is (specifically) the current Debian perspective on LSB status?
Debian 3.0r0 (woody), is close, but not quite, in compliance with LSB 1.2.
The outstanding issues are:
* alien's permissions and ownership handl
On Thu, Aug 15, 2002 at 07:37:10AM -0700, Grant Bowman wrote:
> What is (specifically) the current Debian perspective on LSB status?
http://people.debian.org/~taggart/debconf2/
--
Colin Watson [EMAIL PROTECTED]
What is (specifically) the current Debian perspective on LSB status?
RedHat, SuSE and Mandrake "have become Linux Standard Base (LSB)
Certified." While Bdale's comment is interesting, it does not speak to
Debian's LSB status.
http://www.businesswire.com/cgi-bin/f_headline.cgi
* 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 Smoorenburg <[EMAIL PROTECTED]> [020106 22:23]:
> >> >> Yes, but t
In article <[EMAIL PROTECTED]>,
Grant Bowman <[EMAIL PROTECTED]> wrote:
>* 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
* 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 *.rpm packages. Those don't have to be changed.
> >
In article <[EMAIL PROTECTED]>,
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 *.rpm packages. Those don't have to be changed.
>
>Really? I guess that could be. On w
* 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?
--
-- Grant Bowman
In article <[EMAIL PROTECTED]>,
Grant Bowman <[EMAIL PROTECTED]> wrote:
>Actually, "Init files shall accept one argument, saying what to do" with
>all of {start, stop, restart, reload, force-reload, status} being
>listed. This indicates to me that this is a required change to be LSB
>compliant an
* Anthony Towns [011203 15:33]:
> On Mon, Dec 03, 2001 at 12:04:30PM +0100, Wichert Akkerman wrote:
> > Previously Anthony Towns wrote:
> > > Things break. That's what happen when things fail. You'll notice we don't
> > > guarantee anything better for our own init scripts.
> > LSB does so we will
On Mon, Dec 03, 2001 at 12:04:30PM +0100, Wichert Akkerman wrote:
> Previously Anthony Towns wrote:
> > Things break. That's what happen when things fail. You'll notice we don't
> > guarantee anything better for our own init scripts.
> LSB does so we will need to start caring. You can't selectively
Previously Anthony Towns wrote:
> Things break. That's what happen when things fail. You'll notice we don't
> guarantee anything better for our own init scripts.
LSB does so we will need to start caring. You can't selectively
implement the LSB, that would make the whole thing worthless.
Wichert.
On Mon, Dec 03, 2001 at 01:49:09AM +0100, Wichert Akkerman wrote:
> Previously Anthony Towns wrote:
> > This doesn't need to be done for Debian packages at all (LSB init script
> > dependencies that interact with vendor scripts can all be trivially
> > satisfied by doing all the vendor scripts firs
Previously Anthony Towns wrote:
> This doesn't need to be done for Debian packages at all (LSB init script
> dependencies that interact with vendor scripts can all be trivially
> satisfied by doing all the vendor scripts first), and the dependencies
> for the LSB scripts can be resolved at package
On Sun, Dec 02, 2001 at 01:54:55PM +0100, Wichert Akkerman wrote:
> At the bare minimum we'll need to support dependencies for init scripts
> which means we need to modify most of our own init scripts as well as
> update sysvinit to provide the necessary infrastructure.
This doesn't need to be don
Previously Sean 'Shaleh' Perry wrote:
> we can support the installation of lsb binaries HOWEVER the lsb spec adds a
> 'status' option to init scripts which lsb packages may expect to exist. So at
> the bare minimum we need to support that.
At the bare minimum we'll need to support dependencies fo
* 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 there's any sort of "official" positi
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 there's any sort of "official" position on this, but
mine is that the LSB isn't
In article <[EMAIL PROTECTED]>,
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
>On 28-Nov-2001 Miquel van Smoorenburg wrote:
>>
>> Well no, packages in .lsb that have an /etc/init.d/initscript must
>> support the 'status' option but Debian packages don't have to do
>> that as they are Debian packa
On 28-Nov-2001 Miquel van Smoorenburg wrote:
> According to Sean 'Shaleh' Perry:
>> > If I'm not mistaken that is not nessecary unless we plan to move
>> > all .deb archives over to .lsb too, which is not going to happen.
>> > Debian will stay Debian we just need to make it possible to install
>>
According to Sean 'Shaleh' Perry:
> > If I'm not mistaken that is not nessecary unless we plan to move
> > all .deb archives over to .lsb too, which is not going to happen.
> > Debian will stay Debian we just need to make it possible to install
> > .lsb files *as well*
>
> we can support the inst
On 28-Nov-2001 Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
>>Have you read the lsb? Debian can not at this time claim to support it. We
>>would have to rewrite not only our init scripts but how we do init scripts.
>>Then there
In article <[EMAIL PROTECTED]>,
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
>Have you read the lsb? Debian can not at this time claim to support it. We
>would have to rewrite not only our init scripts but how we do init scripts.
>Then there is the call for specific versions of glibc and a few
On 28-Nov-2001 Grant Bowman wrote:
> Hello,
>
> I see the FHS 2.1 (2.2 is the latest http://www.pathname.com/fhs/) is in
> the Debian-policy 3.5.6.0. I see no mention of LSB in policy 3.5.6
> aside from one small footnote. There's only one bug filed with
> debian-policy but it's about Mesa/G
Hello,
I see the FHS 2.1 (2.2 is the latest http://www.pathname.com/fhs/) is in
the Debian-policy 3.5.6.0. I see no mention of LSB in policy 3.5.6
aside from one small footnote. There's only one bug filed with
debian-policy but it's about Mesa/GL libraries.
It seems to me that a natural step
28 matches
Mail list logo
