Re: init.d scripts and LSB

[Grant Bowman]

* 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.
> 
>   If LSB adoption means that LSB packages shuold be able to run
>  on Debian, yes.

This is a discussion for after Woody is released.  Monaj and Marcus are
starting in, but I think taking up this issue now would simply would
divert effort that's needed for Woody.

Chris, this is a should should.  It's not a should yet, but it should be.

It makes sense to me anyway!

-- 
-- Grant Bowman<[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Marcus Brinkmann]

On Mon, May 06, 2002 at 05:19:07PM +0200, Wichert Akkerman wrote:
> Previously Jeroen Dekkers wrote:
> > Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
> > Debian *BSD should follow the LSB.
> 
> This is a discussion we should be having after the release on a forum
> like debian-project.

Sure, why not.  If there is anything to discuss, that is.
 
> FWIW, I think we should try to use the LSB as much as possible on
> all Debian ports. Please note the name: `port'. It is a port of the
> Debian system to the Linux, Hurd or BSD kernel.

The Hurd is not a kernel.

> We want to have the
> same Debian everywhere instead of suddenly finding ourselves confroned
> with a fork within Debian.

It is Debian GNU/Hurd, so there is no way it can not be Debian.  As for "the
same", there is no way we will follow the LSB up to the ABI specification
for example wrt versioned symbols.  Nor does it make much sense to do so,
except for binary compatibility with GNU/Linux binaries.  Which to make it
useful in the context of Debian requires a whole lot of more meat into the
packaging system.

The LSB is necessary to avoid diversity among GNU/Linux distributions. 
There is only one GNU system, as such no diversity, and all of what the LSB
specifies as far as I have seen it (I have not made a thorough analysis) is
simply defined by the one implementation of the GNU system.

As far as it concerns me, I am not very interested in offering a blanket
statement to follow whatever Linux idiosyncrasy a Linux (exclusively!, they
don't even pretend to specify anything else, which is quite a long way from
the FHS, for example) standard body comes up with.  Not to speak of the
interesting fact that the LSB specifies everything and their mom except
Linux itself (eg the kernel interfaces).

Anyway, your expressed concern is unwarranted.  In fact, we did in the past
some non-trivial work to make it possible to offer the Debian way of doing
things on the Hurd as well, and we will certainly continue to do so.  There
is nothing special in how Debian runs system services, etc, and they can all
be supported by the Hurd, and can be made the default in Debian GNU/Hurd if
people care enough about it.  For example, Roland McGrath split up the init
system to make it possible to use a sysv-style init as used by Debian
GNU/Linux by default.

I don't think that Debian as a whole is interested enough to make policy and
design decisions that really fly on all possible systems, including
non-Linux systems like GNU/Hurd (thanks to Anthony for reminding me where the
priorities are).  So you can not expect that everything that is decided now
or in the past can be carried over literally to the non-Linux ports.  Nor do
we have the resources to really follow every decision and cross check it for
usability on our port (and if we do in individual cases, we might get flamed
for holding up the process against current priorities).  I take it that you
mean that the Debian spirit (technical excellence, no-worries-approach to
installation and upgrading etc) carries over, rather than minute details in
current policies, and this, so far as I can see it, is unharmed by the fact
that the Debian GNU/Hurd group consists of a merry mix of early Debian
members, new members of Debian, and fresh blood.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#146023: suggested patch against policy, documenting "libexec", or current custom on use of "lib" for binaries in lib* packages

[Manoj Srivastava]

>>"Junichi" == Junichi Uekawa <[EMAIL PROTECTED]> writes:

 Junichi> I think this was discussed enough in -devel already, but
 Junichi> some good points about /libexec was given.  I've noticed
 Junichi> that some known good practice is not documented in policy,


Firstly, there is no such consensus that I can see. Secondly,
 I have not seen any technical reason to make Packages
 change. Thirdly, get a rough consensus on -devel, get the packages to
 change, and _then_ we propose a should clause.

 Junichi> and I propose the following patch:

This is way premature.

manoj
-- 
 What fools these morals be!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Manoj Srivastava]

>>"Craig" == Craig Small <[EMAIL PROTECTED]> writes:


 Craig> Should Debian scripts be following the LSB and if so, why
 Craig> doesn't the policy either mention the LSB or have the same
 Craig> standards?

Why on earth should debian init scripts follow the
 requirements for distribution agnostic packaging? Debian packages are
 meant to run on Debian systems, and we can depend on things in debian policy

Debian policy is for Debian packages. LSB is for LSB compliant
 third party packages. All Debian has to do is make sure the LSB
 packages can run on Debian machines.

manoj
-- 
 The meek shall inherit the earth; but by that time there won't be
 anything left worth inheriting.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Manoj Srivastava]

>>"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.

If LSB adoption means that LSB packages shuold be able to run
 on Debian, yes.

 Grant> Init scripts [2] are one point of many related issues.  There
 Grant> has not been consensus on this list.  I believe Bdale (based
 Grant> on his platform) feels similarly.
 Grant> [2] http://www.linuxbase.org/spec/gLSB/gLSB/iniscrptact.html

This has nothing to do with Debian packages; this is a spec
 for LSB packages. There is no requirement for all debian packages to
 be LSB packages.

manoj
-- 
 You recoil from the crude; you tend naturally toward the exquisite.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Craig Small]

On Mon, May 06, 2002 at 04:49:53PM +0200, Jeroen Dekkers wrote:
> Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
> Debian *BSD should follow the LSB. Debian GNU/Hurd is following the
> GNU standards instead of the LSB. Debian *BSD won't follow the LSB
> either, I think they are going to be similar as the existing BSDs.

That would make sense.  I'm trying to see for GNU/Linux if LSB should be
followed and if so is it a SHOULD or a MUST.

I'm getting the impression it is a should.

  - Craig
-- 
Craig Small VK2XLZ  GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Chris Lawrence]

On May 06, Craig Small wrote:
>   I have got bug #138251 which talks about the init.d script and how it
> is missing some nices things etc.
> 
> Should Debian scripts be following the LSB and if so, why doesn't the
> policy either mention the LSB or have the same standards?

FWIW, the current edition of the LSB does require the various LSB
addons, but since the LSB doesn't define any interfaces in /etc/init.d
except those provided by LSB packages, the requirement is meaningless
in practice.

For example, it is illegal for an LSB-conformant application to call
/etc/init.d/apache restart, because /etc/init.d/apache is not defined
in the specification.  Presumably a later edition of the LSB will
define some init.d entry points, but it hasn't happened yet.


Chris
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/

Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Working on debian developer's reference and "best packaging practices"

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  writes:

 Anthony> On Sat, May 04, 2002 at 09:02:24PM -0500, Manoj Srivastava wrote:
 >> >>"Adam" == Adam Heath <[EMAIL PROTECTED]> writes:
 Adam> We(Wichert and I) implement features that users want, when we
 Adam> have time.  We implement those that are interesting to us when
 Adam> we have free time.  I don't think either one of us would feel
 Adam> comfortable being led by another group.
 >> Strawman. The policy group shall never propose additions to
 >> dpkg functionality, the way the section shalll be formulated. What
 >> shall be in the section is what the maintainers _must_ have in order
 >> for their packages to be built.  

 Anthony> That statement's a bit ambiguous.

 Anthony> The real question is whether maintainers are meant to build
 Anthony> using the features of dpkg, or the ones listed in

*Sigh*. Let me see if I can dot the i's and cross the t's. A
 package should be buildable using the bits mentioned in policy. Any
 package may, however, choose to add any extra bits added by dpkg,
 (perhaps buigld depending on a new dpjg version if the change is not
 compatible with older versions).

 Anthony> debian-policy. The former makes sense and works; the latter
 Anthony> means that any new features in dpkg have to go through the
 Anthony> hurdle of debian-policy for no good reason.

No, it does not, unless we are being stupid.

{arguments to ossify the status quo deleted]

manoj
-- 
 Being a miner, as soon as you're too old and tired and sick and
 stupid to do your job properly, you have to go, where the very
 opposite applies with the judges. Beyond the Fringe
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Working on debian developer's reference and "best packaging practices"

[Julian Gilbey]

On Thu, May 02, 2002 at 02:59:36PM -0500, Manoj Srivastava wrote:
>  Julian> People *used* to make that complaint.  And if we now move to having a
>  Julian> lean policy standards document and a developers reference and a best
>  Julian> programming advice document and a dpkg documentation document, we'll
>  Julian> have even more complaints in that direction.
> 
>   I beg to differ. The reason people used to complain was there
>  was no single place one could go to to get a definitive reference for
>  all the things a package maintainer _must_ do in order to achieve
>  interoperability and prevent bug reports.
> 
>   In the new scheme of things, the policy manual would be the
>  place to look at. For further assistance, one could look at the
>  developers reference (HOWTO), the dpkg docs (manual pages for the
>  tools, references), or the style guide (for tips and solutions). There
>  is a well defined destination, depending on what one is looking for. 

I see the value in having a HOWTO; they are always useful.  I have
been convinced that having some sort of split between dpkg
documentation and policy, if done with care, will be beneficial (but
could lead to madness if not).  However, the separation of the style
guide and policy into separate documents does not seem to make sense:
Joe Developer does not know whether his question is a question of
policy or of style when he begins looking.  It would be much clearer
to have a clearly demarcated policy and guidelines manual, where
policy is indicated using MUST, SHOULD, etc., and guidelines does not
use these highlighted terms.  Further, the distinction between policy
and guidelines is not even always very clear or useful, and having a
document which says something like:

  The postinst MUST handle symlinks properly.  Here is some example
  code for achieving this:

if ...

is probably more useful and easier to maintain than:

  The postinst MUST handle symlinks properly.  Example code can be
  found in the guidelines manual, section 3.4.2.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
  website: http://www.maths.qmul.ac.uk/~jdg/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
 Visit http://www.thehungersite.com/ to help feed the hungry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Working on debian developer's reference and "best packaging practices"

[Julian Gilbey]

On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote:
> If the dpkg authors would like to hand off some of their design decisions
> to -policy on a generalised basis, I'm sure they'd say so. It seems a bit,
> well, wrong-headed for -policy to be trying to take control of dpkg though.

Quite: IMHO discussion is about where the documentation should be
found, not about the maintenance or control of dpkg!  The dpkg
developers do a great job, and I have much respect for them.

> >  since potentially large numbers of
> >  packages would be impacted by such changes.
> 
> The dpkg maintainers are well aware of the likely impact of their changes,
> and are quite able to ask for advice when it's needed.
> 
> I'm concerned about this because when I tried passing over
> "release-critical policy issues" to the policy group, it didn't work. Not
> only did everyone regularly and frequently lose track of what the point of
> "must versus should" was, but people just weren't very good at knowing
> when to choose which. Which is fine: we tried an experiment, it didn't
> work out how we'd hope, let's move on. But let's not just repeat the
> same mistake when there's no reason to do so.

Strawman (to quote lots of others).  As a concept, it's very good, but
as we discovered, the implementation was poor.  My suggestion for a
policy rewrite it to move to the standard RFC uses of MUST and SHOULD,
and indication RC-ness in an orthogonal way.  I think this will make
life easier for everyone, and I have no problems at all with the
Release Manager dictating what he considers to be RC for this
particular release.

> Further, considering that everyone seems to think that the -policy
> group have done pretty poorly at their actual job -- maintaining
> the policy document so that it's readable, consistent and useful --
> it doesn't seem like a good idea to broaden its scope. Rewriting it
> into something comprehensible, making the already approved of changes,
> and merging all the subpolicies (at least debconf, perl, and python)
> is likely to be more than enough work for the forseeable future.

Thanks.  Appreciated.  We need to rewrite policy, and have known this
for absolutely ages, but when it absorbed the old packaging manual, it
introduced the contradictions (oops).  I vaguely recall that at that
time, a freeze was effectively placed on substantially rewriting
policy because of the upcoming freeze of woody.  We are still in this
freeze period, and both Manoj and I are itching to rewrite the current
spaghetti which is called policy.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
  website: http://www.maths.qmul.ac.uk/~jdg/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
 Visit http://www.thehungersite.com/ to help feed the hungry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Working on debian developer's reference and "best packaging practices"

[Julian Gilbey]

On Fri, May 03, 2002 at 09:34:58PM +1000, Anthony Towns wrote:
> On Thu, May 02, 2002 at 10:09:11AM +0100, Julian Gilbey wrote:
> > Part I: The Debian Archive
> >  1: DFSG and the sections of the archive (free, non-free, contrib, non-us)
>
> 
> "Components" is a much better word to use here. (And is the word used
> everywhere but -policy, just about)

Fine.

> >  2: The different distributions (stable, etc.)
> 
> I.2 is probably more properly done in the developer's reference, since
> it doesn't impact how you go about constructing an ideal Debian package.

It affects how you write the changelog entry.  So maybe it should go
in both.

> Priorities? Sections?

Yes, of course.

> > Part II: Packages and metadata
[...]

> changelogs? copyright files?

Of course.

> Perhaps something like:
> [...]
> ...would work out well?

Maybe.  Definately worth considering.

> > Then each section could either have the structure:
> >   Policy dictate s
> >   Discussion, useful information, guidelines, examples
> > or we could merge them, and have policy dictates all in the form MUST,
> > SHOULD, MAY, MUST NOT, etc., as in the RFCs. 
> 
> I'm quite confident that trying to differentiate between requirements
> and guidelines like this will turn out to be completely unhelpful and
> a large waste of time, personally.

Don't RFCs do this frequently?  And I've never heard people making
such a complaint about them.

> > (As far as RC issues
> > goes, this could be marked by (RC) after the MUST/SHOULD/whatever,
> > with a catchall at the start of policy that the final decision on what
> > is RC rests with the release manager.)
> 
> As far as RC issues go, they'll be specified in an entirely separate
> document, not maintained by the policy group.

Do you really expect bug submitters to consult yet another document,
or is it just so that you can point people to it and say "See, this is
not considered an RC bug!"?  (I have no objection to there being
another document per se or to the policy group not being in control of
the list of RC issues.)

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
  website: http://www.maths.qmul.ac.uk/~jdg/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
 Visit http://www.thehungersite.com/ to help feed the hungry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The Serious severity

[Marcus Brinkmann]

On Tue, May 07, 2002 at 12:12:16AM +1000, Anthony Towns wrote:
> On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote:
> > I don't care about now, I care about the next release, or the release
> > after that.
> 
> Then how about you spend a moment thinking about it from _my_ perspective
> and stop whining until the next release or the release after that. Yeesh.

If I wait until the next release happens, it is too late to change anything,
and people like you will only tell me to "stop whining" (sic).

Debian development is asynchronous.  You have to adopt to that reality.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#146023: suggested patch against policy, documenting "libexec", or current custom on use of "lib" for binaries in lib* packages

[Junichi Uekawa]

Package: debian-policy
Severity: wishlist

I think this was discussed enough in -devel already, but 
some good points about /libexec was given.
I've noticed that some known good practice is not documented in policy,
and I propose the following patch:


>diff -u policy.sgml{.orig,}
--- policy.sgml.origTue May  7 01:06:15 2002
+++ policy.sgml Tue May  7 01:11:23 2002
@@ -5598,6 +5598,15 @@

 

+ If your package has some run-time support programs that 
+ are required by the shared library, or some unversioned plugin
+ .so files, that may be part of the shared library package.
+ However, to avoid filename clashes, the run-time support 
+ binaries or plugins should reside under the directory
+ /usr/lib/libraryname soversion/
+   
+
+   
  If you have several shared libraries built from the same
  source tree you may lump them all together into a single
  shared library package, provided that you change all of


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4
Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Grant Bowman]

* Wichert Akkerman <[EMAIL PROTECTED]> [020506 08:25]:
> Previously Jeroen Dekkers wrote:
> > Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
> > Debian *BSD should follow the LSB.
> 
> This is a discussion we should be having after the release 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]

Re: The Serious severity

[Jeroen Dekkers]

On Tue, May 07, 2002 at 12:12:16AM +1000, Anthony Towns wrote:
> On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote:
> > I don't care about now, I care about the next release, or the release
> > after that.
> 
> Then how about you spend a moment thinking about it from _my_ perspective
> and stop whining until the next release or the release after that. Yeesh.

He's trying to develop Debian GNU/Hurd and he is pointing out problems
when he is doing that. He's trying to solve those problems, you don't
even want to cooperate and keep saying "think about if from my
perspective". And from talking with Marcus about this thread on IRC, I
know he already did that.

We want to release with woody+1, I hope you will help to make that
possible.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED]
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: [EMAIL PROTECTED]


pgpKemqBfSH82.pgp
Description: PGP signature

Re: init.d scripts and LSB

[Wichert Akkerman]

Previously Jeroen Dekkers wrote:
> Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
> Debian *BSD should follow the LSB.

This is a discussion we should be having after the release on a forum
like debian-project.

FWIW, I think we should try to use the LSB as much as possible on
all Debian ports. Please note the name: `port'. It is a port of the
Debian system to the Linux, Hurd or BSD kernel. We want to have the
same Debian everywhere instead of suddenly finding ourselves confroned
with a fork within Debian.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: init.d scripts and LSB

[Jeroen Dekkers]

On Mon, May 06, 2002 at 01:16:09PM +1000, Craig Small wrote:
> Hello,
>   I have got bug #138251 which talks about the init.d script and how it
> is missing some nices things etc.
> 
> Should Debian scripts be following the LSB and if so, why doesn't the
> policy either mention the LSB or have the same standards?
> 
> This is more important for me as the dh-make maintainer as a lot of
> people use it to make their own packages so I like to get it right.

Debian is more than GNU/Linux. I see no reason why Debian GNU/Hurd and
Debian *BSD should follow the LSB. Debian GNU/Hurd is following the
GNU standards instead of the LSB. Debian *BSD won't follow the LSB
either, I think they are going to be similar as the existing BSDs.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED]
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: [EMAIL PROTECTED]


pgpn966ojGiao.pgp
Description: PGP signature

PRIVATE

[MRS. MARIAM SESE-SEKO]

FROM:MRS. M. SESE-SEKO 

 
 DEAR FRIEND, 

 I AM MRS. MARIAM SESE-SEKO WIDOW OF LATE PRESIDENT 
MOBUTU SESE-SEKO OF ZAIRE? NOW KNOWN AS DEMOCRATIC 
REPUBLIC OF CONGO
(DRC). I AM MOVED TO WRITE YOU THIS LETTER, THIS WAS IN 
CONFIDENCE 
CONSIDERING MY PRESENT CIRCUMSTANCE AND SITUATION. 
 I ESCAPED ALONG WITH MY HUSBAND AND TWO OF OUR SONS 
TIMOTHY AND BASHER OUT OF DEMOCRATIC REPUBLIC OF 
CONGO (DRC) TO 
ABIDJAN,COTE D'IVOIRE WHERE MY FAMILY AND I SETTLED, 
WHILE WE LATER MOVED TO
SETTLED IN MORROCO WHERE MY HUSBAND LATER DIED OF 
CANCER DISEASE. 
  HOWEVER DUE TO THIS SITUATION WE DECIDED TO CHANGED 
MOST OF MY 
HUSBAND'S BILLIONS OF DOLLARS DEPOSITED IN SWISS BANK 
AND OTHER 
COUNTRIES INTO OTHER FORMS OF MONEY CODED FOR SAFE 
PURPOSE BECAUSE THE
NEW HEAD OF STATE OF (DR) MR LAURENT KABILA HAS MADE 
ARRANGEMENT WITH THE
SWISS GOVERNMENT AND OTHER EUROPEAN COUNTRIES TO 
FREEZE ALL MY LATE HUSBAND'S
TREASURES DEPOSITED IN SOME EUROPEAN COUNTRIES. 
HENCE MY CHILDREN AND
I DECIDED LAYING LOW IN AFRICA TO STUDY THE SITUATION TILL 
WHEN THINGS
GETS BETTER, LIKE NOW THAT PRESIDENT KABILA IS DEAD AND 
THE SON TAKING OVER
(JOSEPH KABILA). 
  ONE OF MY LATE HUSBAND'S CHATEAUX IN SOUTHERN FRANCE 
WAS CONFISCATED BY THE FRENCH GOVERNMENT, AND AS 
SUCH I HAD TO CHANGE
MY IDENTITY SO THAT MY INVESTMENT WILL NOT BE TRACED 
AND CONFISCATED. I
HAVE DEPOSITED THE SUM OF EIGHTEEN MLLION UNITED STATE 
DOLLARS 
(US$I8,000,000,00.) WITH A SECURITY COMPANY , FOR 
SAFEKEEPING. THE 
FUNDS ARE SECURITY CODED TO PREVENT THEM FROM 
KNOWING THE CONTENT. 
 WHAT I WANT YOU TO DO IS TO INDICATE YOUR INTEREST  
THAT YOU WILL ASSIST US BY RECEIVING THE MONEY ON OUR 
BEHALF. PLEASE ACKNOWLEDGE THIS  MESSAGE, SO THAT I CAN 
INTRODUCE YOU TO MY FAMILY ATTORNEY (BISI MUSTAPHA) 
WHO HAS THE
OUT  MODALITIES FOR THE CLAIM OF THE SAID FUNDS. I WANT 
YOU TO ASSIST IN 
INVESTING THIS MONEY, BUT I WILL NOT WANT MY IDENTITY 
REVEALED. I WILL ALSO WANT
TO BUY PROPERTIES AND STOCK IN MULTI-NATIONAL 
COMPANIES AND TO ENGAGE IN OTHER
SAFE AND NON-SPECULATIVE INVESTMENTS. MAY I AT THIS 
POINT EMPHASISE THE
HIGH  LEVEL OF CONFIDENTIALITY, WHICH THIS BUSINESS 
DEMANDS, AND HOPE 
YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE, WHICH I 
REPOSE IN YOU.
IN CONCLUSION, IF YOU WANT TO ASSIST US , MY ATTORNEY  
SHALL PUT YOU IN THE 
PICTURE  OF  THE BUSINESS, TELL YOU WHERE THE FUNDS ARE 
CURRENTLY BEING MAINTAINED
AND ALSO DISCUSS OTHER MODALITIES INCLUDING 
REMUNERATION FOR YOUR SERVICES.
 FOR THIS REASON KINDLY FURNISH US YOUR CONTACT  
INFORMATION, THAT IS YOUR PERSONAL TELEPHONE AND FAX 
NUMBER FOR 
CONFIDENTIAL PURPOSE AND ACKNOWLEDGE RECEIPT OF THIS 
MAIL USING THE ABOVE EMAIL 
ADDRESS.

 
BEST REGARDS, 

MRS M. SESE SEKO 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The Serious severity

[Anthony Towns]

On Sat, May 04, 2002 at 10:08:51AM -0400, Marcus Brinkmann wrote:
> I don't care about now, I care about the next release, or the release
> after that.

Then how about you spend a moment thinking about it from _my_ perspective
and stop whining until the next release or the release after that. Yeesh.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


pgpgzrtYVrGAd.pgp
Description: PGP signature

Re: init.d scripts and LSB

[Wichert Akkerman]

Previously Grant Bowman wrote:
> As I've argued late last year [1] Debian should take the necessary
> Policy steps to move forward with LSB adoption.

I agree, but I would like to add we should wait until woody is released.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Working on debian developer's reference and "best packaging practices"

[Anthony Towns]

On Sat, May 04, 2002 at 09:02:24PM -0500, Manoj Srivastava wrote:
> >>"Adam" == Adam Heath <[EMAIL PROTECTED]> writes:
>  Adam> We(Wichert and I) implement features that users want, when we
>  Adam> have time.  We implement those that are interesting to us when
>  Adam> we have free time.  I don't think either one of us would feel
>  Adam> comfortable being led by another group.
>   Strawman. The policy group shall never propose additions to
>  dpkg functionality, the way the section shalll be formulated. What
>  shall be in the section is what the maintainers _must_ have in order
>  for their packages to be built.  

That statement's a bit ambiguous.

The real question is whether maintainers are meant to build using the
features of dpkg, or the ones listed in debian-policy. The former makes
sense and works; the latter means that any new features in dpkg have to
go through the hurdle of debian-policy for no good reason.

We already expect dpkg not to break existing packages, we already are
happy to ignore features in dpkg that are useless, we've no need to
support different implementations of dpkg (anyone remember Herring?) --
and if we did, they'd have to support the undocumented-in-policy features
that some packages will be using anyway -- and we already have a few
people who need to be convinced of any major changes (apt needs to
grok Packages files as well as dpkg, apt-ftparchive needs to be able to
grok .debs and source packages), and we already have plenty of areas to
discuss any changes if discussion is needed.

>   Having that in policy serves two purposes -- it is a quick,
>  minimal reference to the standard interface to packaging tools for
>  debian developers,

Policy is not a HOWTO, and doesn't work as a HOWTO. If you want a quick
minimal dpkg reference, use the packaging manual or the man pages,
or write a HOWTO.

>   and it shall be the common basis that any other
>  packaging tool apart from dpkg must implement in order to qualify.

Like I've already said -- standardisation for standardisation's sake.

>   From time to time, the dpkg authors could ask for additional
>  functions to be added to the core set, at your discretion, when you
>  think it has become a part of the standard interface debian packages
>  have to the packaging system(s).

If stuff's added to policy after it's been tried in various packages,
then it doesn't document enough for reimplementations of dpkg, if it's
added before, it'll have to document things before they've been tried
and demonstrated to be useful.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Novidades

[sem_resposta]

http://www.lojadotelemovel.com/images/riscado_cinza.gif";>






http://www.lojadotelemovel.com/mailing/images/logo.jpg"; 
width="580" height="49">
http://www.lojadotelemovel.com/mailing/images/topo.jpg"; width="580" 
height="93">




http://www.lojadotelemovel.com/product_info.php3?cPath=5&products_id=3624&SESSAO=";>http://www.lojadotelemovel.com/images/anuncios/carrebateria.jpg";>


  
 




 http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; 

height="20" border=0 align="left" width="5"> 
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=3407&SESSAO=";>Antenas
interiores 
   
  
  
http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; 

height="20" border=0 align="left" width="5"> 
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=3534&SESSAO=";>6210-6310
Mistral Bege 


http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; 

height="20" border=0 align="left" width="5"> 
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=3523&SESSAO=";>MC
218 (Psion 5 mx) 

  http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; 

height="20" border=0 align="left" width="5"> 
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=3393&SESSAO=";>Carcaça
mutante   8210-8850 antracite








   
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=2561&SESSAO=";>Carcaça
Nokia 8210-
8310 Azul









   
http://gs.cdnow.com/RP/DMG_ACCUCAST/Special_Offers/graphics/red_arrow.gif"; 
width="10" height="9">http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; height="10" 
border=0 

align="left" width="5">http://www.lojadotelemovel.com/product_info.php3?products_id=2030&SESSAO=";>Adaptador
3SIM Nokia 3310/3330

 


   
   




 


http://www.lojadotelemovel.com/mailing/images/red_arrow.gif";>http://www.lojadotelemovel.com/default.php3?cPath=3_9&SESSAO=";>Kit
Mãos Livres de Isqueiro para Nokia  

http://www.lojadotelemovel.com/default.php3?cPath=3_9&SESSAO=";>http://www.lojadotelemovel.com/images/Kit_isq.jpg"; width="110" 
height="115">
 http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; width="100" 
height="9" 

border="0"> É um
dos mais fantásticos Kit de Mãos Livres para Viatura.
De fácil instalação, liga-se ao isqueiro do automóvel e depois
ao telemóvel.
Possui um potente altifalante com regulador de som;
Botão para carregamento opcional da bateria;
Utiliza o microfone do próprio telemóvel 
  




 http://www.lojadotelemovel.com/mailing/images/red_arrow.gif"; width="10" 
height="9">http://www.lojadotelemovel.com/product_info.php3?products_id=2619&SESSAO=";>A
maior seleção de Carcaças em Portugal  
http://www.lojadotelemovel.com/product_info.php3?cPath=509_522&products_id=3534&SESSAO=";>http://www.lojadotelemovel.com/images/6210MISTRALBEGE.jpg"; 
width="47" height="115">   http://gs.cdnow.com/RP/DMG_ACCUCAST/graphics/spacer.gif"; width="100" 
height="9" 

border="0"> A Lojadotelemovel.com
orgulha-se de apresentar a maior coleção de carcaças em Portugal.
Dispomos de frentes exclusivas para http://www.lojadotelemovel.com/product_info.php3?cPath=509_522&produ

Re: init.d scripts and LSB

[Grant Bowman]

* Craig Small <[EMAIL PROTECTED]> [020505 20:19]:
>   I have got bug #138251 which talks about the init.d script and how it
> is missing some nices things etc.
> 
> Should Debian scripts be following the LSB and if so, why doesn't the
> policy either mention the LSB or have the same standards?
> 
> This is more important for me as the dh-make maintainer as a lot of
> people use it to make their own packages so I like to get it right.
> 
> I'm not on debian-policy, so please CC me.

Hi Craig,

As I've argued late last year [1] Debian should take 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 PROTECTED]>


[1] 
http://lists.debian.org/debian-policy/2001/debian-policy-200111/msg00099.html
The thread spans over November, December and January.

[2] http://www.linuxbase.org/spec/gLSB/gLSB/iniscrptact.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]