Debian-Policy Manual

[David Frey]

My comments on Christian's proposal (which is very good, thank you christian):

>TOPIC 1: policy for user and group ids (uids, gids)

Wouldn't it be better to start the user uid range with 100 as most other
Unices do?

>TOPIC 4: editor/pager policy
What is the benefit of /usr/bin/sensible-{editor,pager}?
Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
if both variables are unset? (auch, don't beat me)

>TOPIC 11: policy about including documentation

Ship info as default. Make a -texi from which texi2html can
create html sources.

> - how "large" may doc files be until they are moved into a 
> seperate package? 
500k?

David


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Kai Henningsen]

[EMAIL PROTECTED] (Francesco Tapparo)  wrote on 22.06.97 in <[EMAIL PROTECTED]>:

> On Jun 22, Kai Henningsen wrote
> > [EMAIL PROTECTED] (Christian Hudon)  wrote on 21.06.97 in
> > <[EMAIL PROTECTED]>:
> >
> > > Newbies should *not* be dumped into vi by default. It's just too
> > > user-hostile.
> >
> > There's only one text mode editor that's not just as user-hostile, and
> > that's ae. That one seems to be completely unacceptable as a default to
> > most non-newbies.
> >
>
> Joe is much better, IMO, and it's very newbie-friendly.

Well, it does mention how to get help, yes. And I do like it.

However, I fear most non-newbies won't like it any better than ae.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Christian Hudon]

On Jun 22, Bruce Perens wrote
> 
> Debian policy for systems 2.0 and above will be to have _no_editor_
> as part of the base system. If you want an editor, you must install

Ahh... That should put an end to the endless editor threads. I'm all for
it.

  Christian

PS Is the bruce-bunchofnumbers address an anti-spam measure? When the
code's ready for prime-time, will you create a Debian package for it? (Or
at least make it available somehow...) I'm interested.



pgpZWSoADLCu8.pgp
Description: PGP signature

Re: Debian-Policy Manual

[Mark Baker]

In article <[EMAIL PROTECTED]>,
David Frey <[EMAIL PROTECTED]> writes:

>>TOPIC 4: editor/pager policy
> What is the benefit of /usr/bin/sensible-{editor,pager}?
> Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> if both variables are unset? (auch, don't beat me)

That might enable us to get rid of /usr/bin/{editor,pager} though it's an
inferior solution to what we're doing at the moment. It won't enable us to
get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
understand EDITOR and PAGER.

Re: Debian-Policy Manual

[Christian Schwarz]

On Mon, 16 Jun 1997, Mark Baker wrote:

> 
> In article <[EMAIL PROTECTED]>,
>   David Frey <[EMAIL PROTECTED]> writes:
> 
> >>TOPIC 4: editor/pager policy
> > What is the benefit of /usr/bin/sensible-{editor,pager}?
> > Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> > if both variables are unset? (auch, don't beat me)
> 
> That might enable us to get rid of /usr/bin/{editor,pager} though it's an
> inferior solution to what we're doing at the moment. It won't enable us to
> get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
> understand EDITOR and PAGER.

Not exactly.

The files /usr/bin/{editor,pager} will be managed through alternatives.
Since alternatives can be changed by the sysadmin only, we allow the user
to define EDITOR and PAGER to override this.

That's why we need "sensible-{editor,pager}". These are two simply shell
scripts that test if EDITOR/PAGER is set and launches either that program,
or /usr/bin/{editor,pager}. 


Thanks,

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[David Frey]

> > David Frey <[EMAIL PROTECTED]> writes:
> > >>TOPIC 4: editor/pager policy
> > > What is the benefit of /usr/bin/sensible-{editor,pager}?
> > > Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> > > if both variables are unset? (auch, don't beat me)
> > 
> > That might enable us to get rid of /usr/bin/{editor,pager} though it's an
> > inferior solution to what we're doing at the moment. It won't enable us to
> > get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
> > understand EDITOR and PAGER.
> 
> Not exactly.
> 
> The files /usr/bin/{editor,pager} will be managed through alternatives.
> Since alternatives can be changed by the sysadmin only, we allow the user
> to define EDITOR and PAGER to override this.
> 
> That's why we need "sensible-{editor,pager}". These are two simply shell
> scripts that test if EDITOR/PAGER is set and launches either that program,
> or /usr/bin/{editor,pager}. 

Im still confused. What do /usr/bin/{editor,pager} do then?
Are they hard links to vi and more? Or equivalently trivial shell scripts
of the form:
#!/bin/sh
/usr/bin/vi

Thanks for your patience,
  David


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Scott Ellis]

On Tue, 17 Jun 1997, David Frey wrote:

> > The files /usr/bin/{editor,pager} will be managed through alternatives.
> > Since alternatives can be changed by the sysadmin only, we allow the user
> > to define EDITOR and PAGER to override this.
> > 
> > That's why we need "sensible-{editor,pager}". These are two simply shell
> > scripts that test if EDITOR/PAGER is set and launches either that program,
> > or /usr/bin/{editor,pager}. 
> 
> Im still confused. What do /usr/bin/{editor,pager} do then?
> Are they hard links to vi and more? Or equivalently trivial shell scripts
> of the form:
> #!/bin/sh
> /usr/bin/vi

I believe that the plan is to have them managed by update-alternatives,
and therefore be symlinks.  Less will probably have a higher priority than
more, although I don't know who gets to win the war over which editor is
best, although I suspect a vi varient on the grounds that that is what
happens on most unices.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Christian Schwarz]

On Sun, 15 Jun 1997, David Frey wrote:

> My comments on Christian's proposal (which is very good, thank you christian):
> 
> >TOPIC 1: policy for user and group ids (uids, gids)
> 
> Wouldn't it be better to start the user uid range with 100 as most other
> Unices do?

Sorry, but I don't get your point. The range from 100-999 is defined to be
for local use of the sysadmin. However, packages can get "dynamically"
UIDs in this range by calling `adduser --system', but only if the sysadmin
has allowed this through the `/etc/adduser.conf' file.

Or did I got your question wrong?


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Christian Hudon]

On Jun 17, Scott Ellis wrote
> 
> I believe that the plan is to have them managed by update-alternatives,
> and therefore be symlinks.  Less will probably have a higher priority than
> more, although I don't know who gets to win the war over which editor is
> best, although I suspect a vi varient on the grounds that that is what
> happens on most unices.

 Here we go again.

Newbies should *not* be dumped into vi by default. It's just too
user-hostile.

  Christian




pgpfORqklxpkK.pgp
Description: PGP signature

Re: Debian-Policy Manual

[Scott K. Ellis]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 21 Jun 1997, Christian Hudon wrote:
> On Jun 17, Scott Ellis wrote
> > I believe that the plan is to have them managed by update-alternatives,
> > and therefore be symlinks.  Less will probably have a higher priority than
> > more, although I don't know who gets to win the war over which editor is
> > best, although I suspect a vi varient on the grounds that that is what
 ^^^
> > happens on most unices.
> 
>  Here we go again.
> 
> Newbies should *not* be dumped into vi by default. It's just too
> user-hostile.

I'm not advocating any particular editor here.  I personally use joe for
brief editing jobs and emacs for the big stuff, but I can understand the
expectations of someone familiar with unix typing vipw or such.

++
|   Scott K. Ellis   |   Argue for your limitations and  |
|   [EMAIL PROTECTED]   | sure enough, they're yours.   |
||-- Illusions   |
++

-BEGIN PGP SIGNATURE-
Version: 2.6.3
Charset: noconv

iQCVAwUBM6wy2KCk2fENdzpVAQEZhgP/e2wVV5B+XL7N+nmI5k6GcFdDr1BApUnR
3JOtnd7uN+A5HLG1ucX/yPFmhAOU+HqlCvU1wMrngCVN33WXrqPEKfjRqwMuvEg9
dt9IlAuMIgSUkEC4PAqiFdq/rdxkrJJ62gyM7lYuJ/yrCgwJEYJIj1JY5Ti5cfNc
hQ1KrIE1QXs=
=gfyf
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Kai Henningsen]

[EMAIL PROTECTED] (Christian Hudon)  wrote on 21.06.97 in <[EMAIL PROTECTED]>:

> Newbies should *not* be dumped into vi by default. It's just too
> user-hostile.

There's only one text mode editor that's not just as user-hostile, and  
that's ae. That one seems to be completely unacceptable as a default to  
most non-newbies.

Now what?

I think vi is indeed the right solution. People expect vi with Unix, and  
if they want to configure something different, they always can.

If you want to have something as idiot-accessible as Windows (note: I'm  
not talking about system configuration here - that one is a nightmare on  
Windows!), then you need to do everything in the GUI. In that case, it's  
completely irrelevant what is the default text mode editor.

And remember, you can always override update-alternatives and change that  
default. You could even write a package that presents you with a menu of  
installed editors, and lets you choose which one to make the default.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Francesco Tapparo]

On Jun 22, Kai Henningsen wrote
> [EMAIL PROTECTED] (Christian Hudon)  wrote on 21.06.97 in <[EMAIL PROTECTED]>:
> 
> > Newbies should *not* be dumped into vi by default. It's just too
> > user-hostile.
> 
> There's only one text mode editor that's not just as user-hostile, and  
> that's ae. That one seems to be completely unacceptable as a default to  
> most non-newbies.
> 

Joe is much better, IMO, and it's very newbie-friendly.

> Now what?
> 
> I think vi is indeed the right solution. People expect vi with Unix, and  
> if they want to configure something different, they always can.

I think that our default configuration must be newbie-friendly: if a expert
user will change the configuration, he will make it with no trouble.

> If you want to have something as idiot-accessible as Windows (note: I'm  
> not talking about system configuration here - that one is a nightmare on  
> Windows!), then you need to do everything in the GUI. In that case, it's  
> completely irrelevant what is the default text mode editor.

There are many newbie, that use Linux without X, for memory problems or for
taste questions: they're a "market" important for Linux, IMO.

. snip 

Ciao
Francesco Tapparo
[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Francesco Tapparo]

On Jun 22, James Troup wrote
> Francesco Tapparo <[EMAIL PROTECTED]> writes:
> 
> > Joe is much better, IMO, and it's very newbie-friendly.
> 
> hades|14:07:32 ~ [507] $ls -l $(type -path joe) $(type -path ae)
> -rwxr-xr-x   1 root root23968 May  5 01:36 /bin/ae
> -rwxr-xr-x   5 root root   171916 Nov 24  1996 /usr/bin/joe

Of course ae will be used in the boot disks, but in the default
installation, joe must be the choiche, IMO.

Francesco Tapparo
[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian-Policy Manual

[Bruce Perens]

From: Francesco Tapparo <[EMAIL PROTECTED]>
> Of course ae will be used in the boot disks, but in the default
> installation, joe must be the choiche, IMO.

Debian policy for systems 2.0 and above will be to have _no_editor_
as part of the base system. If you want an editor, you must install
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

QUESTION: Debian Policy: Manual pages

[Harshula]

Hi,

re: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
---
Each program, utility, and function should have an associated manual
page included in the same package. It is suggested that all
configuration files also have a manual page included as well. Manual
pages for protocols and other auxiliary things are optional.

If no manual page is available, this is considered as a bug and should
be reported to the Debian Bug Tracking System (the maintainer of the
package is allowed to write this bug report themselves, if they so
desire). Do not close the bug report until a proper man page is
available.[80]
---

Here's the example:

1) a.tar.gz -> a.deb
2) b.tar.gz -> b.deb
3) c.tar.gz -> c.deb

c.tar.gz contains only documentation, including man pages for
binaries/scripts in a.tar.gz and b.tar.gz.

Since c.deb contains all the man pages, running lintian on a.deb results
in:
---
W: m17n-db: binary-without-manpage usr/bin/m17n-db
N:
N:   Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games
should
N:   have a manual page
N:   
N:   Note, that though the `man' program has the capability to check for
N:   several program names in the NAMES section, each of these programs
N:   should have its own manual page (a symbolic link to the appropriate
N:   manual page is sufficient) because other manual page viewers such
as
N:   xman or tkman don't support this.
N:   
N:   Refer to Policy Manual, section 12.1 for details.
N:
---

What is the recommended way to deal with this scenario?

cya,
#


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

Re: QUESTION: Debian Policy: Manual pages

[Thibaut Paumard]

Le 14 févr. 08 à 17:04, Harshula a écrit :


Hi,

re: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
---
Each program, utility, and function should have an associated manual
page included in the same package. [...]
---

Here's the example:

1) a.tar.gz -> a.deb
2) b.tar.gz -> b.deb
3) c.tar.gz -> c.deb

c.tar.gz contains only documentation, including man pages for
binaries/scripts in a.tar.gz and b.tar.gz.
[example of lintian warnings]
What is the recommended way to deal with this scenario?


My point-of-view is that it's fine IF the package which contains the  
binaries Depends: on the package which contains the manpage. In that  
case, you may write a lintian override.

(Note: IANADD... BADM)

Regards, Thibaut.

Re: QUESTION: Debian Policy: Manual pages

[Leo "costela" Antunes]

Hi

Firstly, this kind of question would be better suited in the
debian-mentors list.

Harshula wrote:
> Here's the example:
> 
> 1) a.tar.gz -> a.deb
> 2) b.tar.gz -> b.deb
> 3) c.tar.gz -> c.deb
> 

Are they really distributed in three separate upstream tarballs? If they
are, perhaps it would be better to generate a single tarball, if not,
there's no need to split it. A single tarball can - and most do -
generate many separate debs. Take a look at the New Maintainer Guide[0]
or get the sources of some existing packages to get the hang of it.

This should solve the manpage issue.


Cheers

[0] http://www.debian.org/doc/maint-guide/

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: QUESTION: Debian Policy: Manual pages

[Felipe Sateler]

Harshula wrote:

> Hi,
> 
> re: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
> ---
> Each program, utility, and function should have an associated manual
> page included in the same package. It is suggested that all
> configuration files also have a manual page included as well. Manual
> pages for protocols and other auxiliary things are optional.
> 
> If no manual page is available, this is considered as a bug and should
> be reported to the Debian Bug Tracking System (the maintainer of the
> package is allowed to write this bug report themselves, if they so
> desire). Do not close the bug report until a proper man page is
> available.[80]
> ---
> 
> Here's the example:
> 
> 1) a.tar.gz -> a.deb
> 2) b.tar.gz -> b.deb
> 3) c.tar.gz -> c.deb
> 
> c.tar.gz contains only documentation, including man pages for
> binaries/scripts in a.tar.gz and b.tar.gz.

> What is the recommended way to deal with this scenario?

If the three tarballs are released in sync, it may be possible to repack all
three as one source tarball for debian.

-- 

  Felipe Sateler


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

Re: QUESTION: Debian Policy: Manual pages

[Josselin Mouette]

Le vendredi 15 février 2008 à 03:04 +1100, Harshula a écrit :
> 1) a.tar.gz -> a.deb
> 2) b.tar.gz -> b.deb
> 3) c.tar.gz -> c.deb
> 
> c.tar.gz contains only documentation, including man pages for
> binaries/scripts in a.tar.gz and b.tar.gz.

Then a and b should Recommend: c, regardless of how the upstream
tarballs are packaged. All the rest is superfluous. Just ignore the
lintian warning or add an override, 

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: QUESTION: Debian Policy: Manual pages

[Russ Allbery]

Harshula <[EMAIL PROTECTED]> writes:

> Since c.deb contains all the man pages, running lintian on a.deb results
> in:
> ---
> W: m17n-db: binary-without-manpage usr/bin/m17n-db
> N:
> N:   Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games
> should
> N:   have a manual page
> N:   
> N:   Note, that though the `man' program has the capability to check for
> N:   several program names in the NAMES section, each of these programs
> N:   should have its own manual page (a symbolic link to the appropriate
> N:   manual page is sufficient) because other manual page viewers such
> as
> N:   xman or tkman don't support this.
> N:   
> N:   Refer to Policy Manual, section 12.1 for details.
> N:
> ---
>
> What is the recommended way to deal with this scenario?

I thought that tag in lintian already had a note that you should add an
override if the man pages are shipped in a different package on which this
package has a dependency.  Apparently I was just imagining things.

Such a note will be present in the next release.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: QUESTION: Debian Policy: Manual pages

[Bas Zoetekouw]

Hi Josselin!

You wrote:

> Le vendredi 15 février 2008 à 03:04 +1100, Harshula a écrit :
> > 1) a.tar.gz -> a.deb
> > 2) b.tar.gz -> b.deb
> > 3) c.tar.gz -> c.deb
> > 
> > c.tar.gz contains only documentation, including man pages for
> > binaries/scripts in a.tar.gz and b.tar.gz.
> 
> Then a and b should Recommend: c, regardless of how the upstream
> tarballs are packaged. All the rest is superfluous. Just ignore the
> lintian warning or add an override, 

Why a recommends?  In order to satisfy the spirit of policy ("every
binary must have a man page") it would need to be a depends, imo.

-- 
Kind regards,
Bas Zoetekouw.


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

Re: QUESTION: Debian Policy: Manual pages

[Cyril Brulebois]

On 14/02/2008, Russ Allbery wrote:
> I thought that tag in lintian already had a note that you should add
> an override if the man pages are shipped in a different package on
> which this package has a dependency. Apparently I was just imagining
> things.

ISTR it's the case for icons in desktop/menu files.

-- 
Cyril Brulebois


pgpGmD9xFI6pW.pgp
Description: PGP signature

Re: QUESTION: Debian Policy: Manual pages

[Harshula]

Hi,

Answers:

a) Yes, they are *really* distributed in three separate tarballs.
b) The three tarballs are not released in sync.

Conclusion:

1) a.deb & b.deb shall depend on c.deb
2) a.deb & b.deb shall contain lintian overrides.

Thanks for the useful feedback!

[NOTE: If replying, please keep my email address in the TO/CC list]

cya,
#

On Fri, 2008-02-15 at 03:04 +1100, Harshula wrote:
> Hi,
> 
> re: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
> ---
> Each program, utility, and function should have an associated manual
> page included in the same package. It is suggested that all
> configuration files also have a manual page included as well. Manual
> pages for protocols and other auxiliary things are optional.
> 
> If no manual page is available, this is considered as a bug and should
> be reported to the Debian Bug Tracking System (the maintainer of the
> package is allowed to write this bug report themselves, if they so
> desire). Do not close the bug report until a proper man page is
> available.[80]
> ---
> 
> Here's the example:
> 
> 1) a.tar.gz -> a.deb
> 2) b.tar.gz -> b.deb
> 3) c.tar.gz -> c.deb
> 
> c.tar.gz contains only documentation, including man pages for
> binaries/scripts in a.tar.gz and b.tar.gz.
> 
> Since c.deb contains all the man pages, running lintian on a.deb results
> in:
> ---
> W: m17n-db: binary-without-manpage usr/bin/m17n-db
> N:
> N:   Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games
> should
> N:   have a manual page
> N:   
> N:   Note, that though the `man' program has the capability to check for
> N:   several program names in the NAMES section, each of these programs
> N:   should have its own manual page (a symbolic link to the appropriate
> N:   manual page is sufficient) because other manual page viewers such
> as
> N:   xman or tkman don't support this.
> N:   
> N:   Refer to Policy Manual, section 12.1 for details.
> N:
> ---
> 
> What is the recommended way to deal with this scenario?
> 
> cya,
> #


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

Re: QUESTION: Debian Policy: Manual pages

[Ian Jackson]

Bas Zoetekouw writes ("Re: QUESTION: Debian Policy: Manual pages"):
> Why a recommends?  In order to satisfy the spirit of policy ("every
> binary must have a man page") it would need to be a depends, imo.

I think the point of policy is to ensure the manpage exists, not to
require that it be installed.

I think Suggests is the right dependency.  There is nothing wrong with
installing a package without its documentation.

Ian.


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

Re: QUESTION: Debian Policy: Manual pages

[Marvin Renich]

* Ian Jackson <[EMAIL PROTECTED]> [080224 09:18]:
> Bas Zoetekouw writes ("Re: QUESTION: Debian Policy: Manual pages"):
> > Why a recommends?  In order to satisfy the spirit of policy ("every
> > binary must have a man page") it would need to be a depends, imo.
> 
> I think the point of policy is to ensure the manpage exists, not to
> require that it be installed.
> 
> I think Suggests is the right dependency.  There is nothing wrong with
> installing a package without its documentation.
> 
> Ian.
> 

IANADD, but as a user, I disagree.  Policy [12.1] states:

  Each program, utility, and function should have an associated manual
  page included in the same package.

There is a big difference between a man page and more complete
documentation like a User Manual.

I _expect_ a man page for every executable.  A Depends, in my mind,
clearly satisfies the policy requirement, as the man page will be
available unless I use dpkg --force-* or some other drastic measure to
override the depends.  A Recommends may satisfy this (especially now
that apt defaults to installing them), but not quite as clearly.

Harshula, from your description it is not clear if c.tar.gz contains
substantial documentation beyond man pages.  If c.tar.gz contains very
little besides man pages and basic documentation, then Depend on c.deb,
and leave the man pages there.  If the tarball contains a lot of other
documentation, my preference as a user would be to have the man pages
moved into the binary a.deb and b.deb packages, and Recommend or Suggest
c.deb (without the man pages).

If you are making one source package with three binary packages, moving
the man pages to a different binary package is trivial.  If you are
making three separate source packages, I would still prefer to have the
man pages copied to the packages with their corresponding executable,
with a note in the README.Debian identifying the originating tarball.

I know this is more work (in the separate source package case), but as a
user I would appreciate not having to keep around a large documentation
package just to get man pages.

...Marvin


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

ANNOUNCEMENT: Home Page for Debian Policy Manual

[Christian Schwarz]

Hi folks!

I've set up a new web page for all Debian Policy related info. The URL is

http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/

The page contains the newest Policy Manual (2.1.3.3) in different formats,
as well as the Filesystem Structure (FSSTND), and the virtual package name
list. 

In addition, some old versions of the policy manual are also included,
together with "u-diffs".

The page contains a link to the current DRAFT version, that is, the copy
I'm working on right now. Note, that this is not more than a "snapshot
release". It is to be considered "unstable" :-) This manual also contains
a few sections which have not yet been approved here on debian-devel --
I'll do this in a few days.

Feel free to send me any suggestions, critics, etc.


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)

[Jonathan de Boyne Pollard]

Robert Edmonds:


The relevant text from the policy manual, §9.11: [...]

The Debian Policy Manual never got updated in the wake of the Debian 
systemd Hoo-Hah.  It remains written from the viewpoint that System 5 
init and rc are the defaults, and that upstart is a novelty addendum.  
Several people in 2014 publicly proposed starting a Policy Manual 
revision.  They never finished, to my knowledge, and their proposals 
remain part-done (to this day, as far as I know, although I haven't 
re-checked since 2015).  I didn't make a public announcement, and just 
got on and did a rewrite.  (-:


It is here, complete with SGML patch: 
https://jdebp.eu./Proposals/DebianPolicy/

Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)

[Jonathan de Boyne Pollard]

Robert Edmonds:


The relevant text from the policy manual, §9.11: [...]


Ansgar Burchardt:

Was that changed since the default init system was changed?  It pretty 
much still reads like Policy still assumes that sysvinit is the 
default init system.  It also still mentions upstart in 9.11.1; will 
file a bug for that. If it wasn't changed, just s/sysvinit/systemd/ 
mentally ;)  It's not the only place where Policy lags behind what is 
actual practice.


For your bug, please note that the grunt work of fixing Debian Policy 
has already been done long since, and a patch exists:


* https://jdebp.eu./Proposals/DebianPolicy/