Your message dated Thu, 20 Feb 2020 01:34:27 +
with message-id
and subject line Bug#484804: fixed in developers-reference 11.0.9
has caused the Debian Bug report #484804,
regarding developers-reference: please add a suggestion to comment a "wontfix"
to be marked as done.
This mean
Your message dated Sat, 30 Nov 2019 01:34:09 +
with message-id
and subject line Bug#944325: fixed in debian-policy 4.4.1.2
has caused the Debian Bug report #944325,
regarding please fix this unclear and obtuse phrasing in §7.8 (suggestion
provided)
to be marked as done.
This means that you
control: tag -1 +pending
Hello Nicholas,
On Fri 29 Nov 2019 at 01:26PM -05, Nicholas D Steeves wrote:
> At any rate, I've submitted an update MR here (see previous email for
> extended rationale):
>
> https://salsa.debian.org/sten-guest/policy/merge_requests/3
Thank you for preparing a patch.
Processing control commands:
> tag -1 +pending
Bug #944325 [debian-policy] please fix this unclear and obtuse phrasing in §7.8
(suggestion provided)
Added tag(s) pending.
--
944325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944325
Debian Bug Tracking System
Contact
Hi Sean,
Sean Whitton writes:
> Hello Nicholas,
>
> I am not sure what is going on with your (1), (2) and (3). Perhaps you
> could propose your change in the form of a patch.
>
Those numbers refer to annotations in the quoted portion. IIRC you're
also using notmuch mode, so
[ x more citati
Hello Nicholas,
I am not sure what is going on with your (1), (2) and (3). Perhaps you
could propose your change in the form of a patch.
--
Sean Whitton
signature.asc
Description: PGP signature
Sean Whitton writes:
> Hello,
>
> On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
>
>> How about:
>>
>> [1] This field should only be used when there are license or DFSG
>> requirements to retain the referenced source package. [2] It should not
>> be added solely as a way to l
On Sun, 17 Nov 2019 17:01:21 -0700, Sean Whitton wrote:
> On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
> > How about:
> >
> > This field should only be used when there are license or DFSG
> > requirements to retain the referenced source package. It should not
> > be added so
Hello,
On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:
> How about:
>
> This field should only be used when there are license or DFSG
> requirements to retain the referenced source package. It should not
> be added solely as a way to locate packages that need to be rebuilt
>
Sean Whitton writes:
> diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> index 140fdf1..8e4d98a 100644
> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst
> @@ -661,11 +661,10 @@ field in its control file:
> Built-Using: grub2 (= 1.99-9), loadlin (
Hello Nicholas,
On Fri 08 Nov 2019 at 03:09PM -05, Nicholas D Steeves wrote:
> You're welcome :-) Done!
> https://salsa.debian.org/sten-guest/policy/merge_requests/2
Hmm, this patch isn't what you proposed in your previous mail:
diff --git a/policy/ch-relationships.rst b/policy/ch-relationsh
On Fri, Nov 08, 2019 at 10:53:31AM -0700, Sean Whitton wrote:
> On Thu 07 Nov 2019 at 04:51PM -05, Nicholas D Steeves wrote:
>
> > I suggest replacing the whole sentence with "The purpose of this field
> > is exclusively for cases where a package's license, or when DFSG
> > requirements, necessita
Hello,
On Thu 07 Nov 2019 at 04:51PM -05, Nicholas D Steeves wrote:
> The full sentence in question is "This field should not be added
> solely for purposes other than satisfying license or DFSG requirements
> to provide full source code".
>
> "solely for purposes other than satisfying" is the pr
Package: debian-policy
Version: 4.4.1.1
Severity: normal
The full sentence in question is "This field should not be added
solely for purposes other than satisfying license or DFSG requirements
to provide full source code".
"solely for purposes other than satisfying" is the problematic
constructio
Your message dated Sat, 15 Sep 2018 17:52:17 +0200
with message-id <439ff8d2eaf8443e6476af56ba39ecc37a09ede0.ca...@debian.org>
and subject line Re: developers-reference: Lintian contradicts suggestion in
maintainer scripts best practices
has caused the Debian Bug report #825047,
reg
ainer
script,...
~~~
Given the lintian warning above, the first suggestion quoted here probably
should not be made in the Developer's reference.
Many thanks and regards
Afif
Your message dated Sun, 31 Jul 2011 18:17:32 +
with message-id
and subject line Bug#540249: fixed in developers-reference 3.4.6
has caused the Debian Bug report #540249,
regarding Suggestion to discuss emeritus keyring as part of "Retiring" section
to be marked as done.
This mean
Your message dated Fri, 26 Nov 2010 12:02:06 +
with message-id
and subject line Bug#557298: fixed in developers-reference 3.4.4
has caused the Debian Bug report #557298,
regarding developers-reference: Suggestion for manpage formats easier than
troff.
to be marked as done.
This means that
On Tue, 29 Jun 2010, Russ Allbery wrote:
> Russ Allbery writes:
>
> > I therefore propose adding GPL version 1 to the list of licenses said by
> > Policy to be in common-licenses and asking Santiago to include a copy in
> > base-files. I'm not including a diff since it would just create merge
>
Russ Allbery writes:
> I therefore propose adding GPL version 1 to the list of licenses said by
> Policy to be in common-licenses and asking Santiago to include a copy in
> base-files. I'm not including a diff since it would just create merge
> conflicts with the BSD diff proposed earlier today
On Mon, 2010-06-28 at 10:58 -0700, Russ Allbery wrote:
> Andrew McMillan writes:
> > On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote:
>
> >> Ok, I agree that it would a good idea to include GPL-1 in common-licenses
> >> because of the high number of packages still using it.
>
> > I'm sorr
Andrew McMillan writes:
> On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote:
>> Ok, I agree that it would a good idea to include GPL-1 in common-licenses
>> because of the high number of packages still using it.
> I'm sorry, but I disagree, for the time being. I do not believe that
> large
Santiago Vila writes:
> Then we usually add this little blurb:
> On Debian GNU/Linux systems, the complete text of the GNU General
> Public License can be found in `/usr/share/common-licenses/GPL'.
> which is an addon to the previous paragraph, so it's for informational
> purposes as well.
> T
Andrew McMillan writes:
> On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote:
>> Ok, I agree that it would a good idea to include GPL-1 in
>> common-licenses because of the high number of packages still using it.
> I'm sorry, but I disagree, for the time being. I do not believe that
> large
On Fri, 2010-06-11 at 14:40 +0200, gregor herrmann wrote:
> On Sat, 12 Jun 2010 00:25:57 +1200, Andrew McMillan wrote:
>
> > If the code is v1-or-later then a trivial fork (by the original
> > developer) is able to relicense it as v2-or-later or v3-or-later. If
> > the original developer is unhap
On Sat, 12 Jun 2010 00:25:57 +1200, Andrew McMillan wrote:
> If the code is v1-or-later then a trivial fork (by the original
> developer) is able to relicense it as v2-or-later or v3-or-later. If
> the original developer is unhappy with doing that, then they do have
> uncommon licensing desires.
On 11.06.2010 14:25, Andrew McMillan wrote:
If the code is v1-or-later then a trivial fork (by the original
developer) is able to relicense it as v2-or-later or v3-or-later. If
the original developer is unhappy with doing that, then they do have
uncommon licensing desires.
It would be illegal
On Fri, 2010-06-11 at 14:14 +0200, Giacomo A. Catenazzi wrote:
>
> Yes for new code, but old code cannot be relicensed easily:
> all authors should agree, but GPLv1 is very old, in periods
> where contribution did not have an email and "fix" (live-long)
> email address was not common.
It is:
(a)
On 11.06.2010 13:16, Andrew McMillan wrote:
On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote:
Ok, I agree that it would a good idea to include GPL-1 in common-licenses
because of the high number of packages still using it.
I'm sorry, but I disagree, for the time being. I do not believe
On Fri, 2010-06-11 at 11:35 +0200, Santiago Vila wrote:
>
> Ok, I agree that it would a good idea to include GPL-1 in common-licenses
> because of the high number of packages still using it.
I'm sorry, but I disagree, for the time being. I do not believe that
large numbers of packages are delibe
On Thu, 10 Jun 2010, Russ Allbery wrote:
> Given that, while I'm very sympathetic to Santiago's argument, I also
> think that we should be able to represent in packages their upstream
> licensing statement and not be implicitly relicensing them under later
> versions of the GPL, and without includ
-=| gregor herrmann, Fri, Jun 11, 2010 at 12:50:36AM +0200 |=-
> On Thu, 10 Jun 2010 14:54:45 -0700, Russ Allbery wrote:
> > I therefore propose adding GPL version 1 to the list of licenses
> > said by
> > Policy to be in common-licenses and asking Santiago to include a copy in
> > base-files. I'
On Thu, 10 Jun 2010 14:54:45 -0700, Russ Allbery wrote:
> Given that, while I'm very sympathetic to Santiago's argument, I also
> think that we should be able to represent in packages their upstream
> licensing statement and not be implicitly relicensing them under later
> versions of the GPL,
A
Santiago Vila writes:
> On Sun, 5 Aug 2007, Sam Hocevar wrote:
>>There are still many packages that mention the GPL version 1 in
>> their copyright file (around 350). Many Perl packages, but also Perl
>> itself and widespread things like sed, joe, cvs, dict...
>>There are also countless
On Wed, 03 Feb 2010, Brandon wrote:
> I bet there will be several. On my system currently, xcdroast and
I think this is a holdover from when xcdroast asked a debconf
question; it's probably a bug that that code is still there... file
it!
> xsendmail use stat overrides unnecessarily.
I don't know
also sprach martin f krafft [2010.02.04.1336 +1300]:
> In short, I am in favour of forbidding use of dpkg-statoverride by
> package maintainers, unless I missed something in the above.
Further information from IRC:
< madduck> sgran: feel free to slam me down on my latest
reply to #568313 wrt t
On Thu, 04 Feb 2010, martin f krafft wrote:
> I can perfectly understand admins wanting to override package
> defaults, but not why the package maintainer needs to use
> dpkg-statoverride.
You need to use dpkg-statoverride when you are using a dynamic uid/gid
and files that you ship need to be set
martin f krafft writes:
> I tend to agree. With that in mind, though, why would one ever want/need
> to chmod/chown files under control by dpkg (which are the only ones for
> which dpkg-statoverride applies to) *from postinst*? I can perfectly
> understand admins wanting to override package defa
also sprach Russ Allbery [2010.02.04.1245 +1300]:
> I suppose it's a question of what the best defaults are, but I prefer the
> behavior of assuming the ownership and permissions shipped in the package
> are correct and the installed files should be modified to match. The case
> where I want to p
Brandon writes:
> I still think that dpkg-statoverride should be forbidden in the case
> where the uid and gid are static.
Policy basically already does that, doesn't it? It's not normative (maybe
it should be), but that's how I always read 10.9.1:
Given the above, dpkg-statoverride is ess
retitle 568313 Suggestion: forbid the use of dpkg-statoverride when uid and gid
are static
thanks
You're right Russ. In that scenario, there would a be a short period of
time where the permissions would not be set correctly.
I still think that dpkg-statoverride should be forbidden in the
Processing commands for cont...@bugs.debian.org:
> retitle 568313 Suggestion: forbid the use of dpkg-statoverride when uid and
> gid are static
Bug #568313 [debian-policy] Suggestion: forbid the use of dpkg-statoverride in
postinst scripts, except for --list
Changed Bug title to '
This one time, at band camp, Brandon said:
> As for setting permissions for files with dynamic ids, debian policy
> says that dpkg-statoverride is necessary. This is not true, or at least
> misleading.
How do you expect packages to maintain correct ownerships and
permissions on files owned by dyna
Brandon writes:
>> If you set the permissions with chown, aren't they overwritten every
>> time the package is upgraded and then have to be reset again
> No. You have to check for overrides first, and only chown/chmod if there
> aren't any in place. You have to do this regardless of which metho
On Thu, 4 Feb 2010 12:36:34 +1300
martin f krafft wrote:
> also sprach Russ Allbery [2010.02.04.1222 +1300]:
> > If you set the permissions with chown, aren't they overwritten
> > every time the package is upgraded and then have to be reset again,
> > leaving windows on every upgrade when they h
martin f krafft writes:
> also sprach Russ Allbery [2010.02.04.1222 +1300]:
>> If you set the permissions with chown, aren't they overwritten every
>> time the package is upgraded and then have to be reset again, leaving
>> windows on every upgrade when they have the wrong permissions?
> Maybe
> leaving windows on every upgrade when they have the wrong permissions?
Oh. I know what this means now. I was thinking of glass windows. Or
maybe MS Windows. There is no point in time where the user would have
the wrong permissions, as long as the package scripts are done
correctly.
-Brandon
s
also sprach Russ Allbery [2010.02.04.1222 +1300]:
> If you set the permissions with chown, aren't they overwritten every time
> the package is upgraded and then have to be reset again, leaving windows
> on every upgrade when they have the wrong permissions?
Maybe dpkg could be taught to preserve
> > As for setting permissions for files with dynamic ids, debian policy
> > says that dpkg-statoverride is necessary. This is not true, or at
> > least misleading. Certainly the post install script should check to
> > make sure that there isn't any override in place before setting
> > file permiss
Brandon writes:
> As for setting permissions for files with dynamic ids, debian policy
> says that dpkg-statoverride is necessary. This is not true, or at least
> misleading. Certainly the post install script should check to make sure
> that there isn't any override in place before setting file p
To give everyone an idea of how much simpler the package scripts are
that don't use dpkg-statoverride to set permissions, here is the example
from the policy document:
postinst:
for i in /usr/bin/foo /usr/sbin/bar
do
# only do something when no setting exists
if ! dpkg-stat
> > First, I suggest that Debian Policy require, or at least recommend,
> > that packages not use dpkg-statoverride to set permissions for files
> > with static uids and gids. In other words, if it is possible for the
> > maintainer to set the permissions in the package binary itself, then
> > he s
On Wed, 03 Feb 2010, Brandon wrote:
> First, I suggest that Debian Policy require, or at least recommend,
> that packages not use dpkg-statoverride to set permissions for files
> with static uids and gids. In other words, if it is possible for the
> maintainer to set the permissions in the package
Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
Regarding Debian Policy 10.9.
First, I suggest that Debian Policy require, or at least recommend,
that packages not use dpkg-statoverride to set permissions for files
with static uids and gids. In other words, if it is possible for the
ma
tags 557298 pending
thanks
On Sat, 21 Nov 2009, Charles Plessy wrote:
> Index: best-pkging-practices.dbk
> ===
> --- best-pkging-practices.dbk (révision 6986)
> +++ best-pkging-practices.dbk (copie de travail)
> @@ -1484,6 +1484,20 @@
Processing commands for cont...@bugs.debian.org:
> tags 557298 pending
Bug #557298 [developers-reference] developers-reference: Suggestion for manpage
formats easier than troff.
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debi
Package: developers-reference
Version: 3.4.3
Severity: normal
Tags: patch
Dear all,
Here is a patch to the Developers Reference, that aims at stimulating manpage
writing by suggesting DocBook, POD and reST as source format to the maintainers
uncomfortable with troff.
It summarises the collective
On Thu, Aug 23, 2007 at 01:28:22PM +0200, Santiago Vila wrote:
>>There are still many packages that mention the GPL version 1 in
>> their copyright file (around 350). Many Perl packages, but also
>> Perl itself and widespread things like sed, joe, cvs, dict...
Nitpick: sed says GPLv2 or later
Processing commands for [EMAIL PROTECTED]:
> reassign 436105 debian-policy
Bug#436105: suggestion to add GPL-1 as a common licence
Bug reassigned from package `base-files' to `debian-policy'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Deb
reassign 436105 debian-policy
thanks
On Sun, 5 Aug 2007, Sam Hocevar wrote:
> Package: base-files
> Version: 4.0.0
> Severity: wishlist
>
>There are still many packages that mention the GPL version 1 in their
> copyright file (around 350). Many Perl packages, but also Perl itself
> and wides
On Wed, Jun 22, 2005 at 10:41:39AM +0200, Lukas Kolbe wrote:
> I don't really see a problem here.
>
> The FHS dictates: /src is site-specific.
> The Policy dictates: webapps-files in /usr/share/package/, which I
> strongly agree.
>
> Now, what prevents u
I don't really see a problem here.
The FHS dictates: /src is site-specific.
The Policy dictates: webapps-files in /usr/share/package/, which I
strongly agree.
Now, what prevents us writing helper-packages to maintain a subset of,
say, /srv/webapps/?
It could be, like Kai said, /srv/[webapps|www]
On Thu, Jan 09, 2003 at 05:19:59PM +0100, Josip Rodin wrote:
> On Thu, Jan 09, 2003 at 05:11:11PM +0100, Gerd Knorr wrote:
>
> > xawtv wants to know: when it creates all the windows and widgets at
> > startup time. There is a menu with the available codecs in the
> > record dialog ...
>
> Yeah,
On Thu, Jan 09, 2003 at 05:11:11PM +0100, Gerd Knorr wrote:
> > > It caches information to reduce startup times. dlopen() 10 *.so files
> > > and doing various function calls to get all the info stored in that file
> > > takes some time ...
> >
> > Yeah but I _don't_ _need_ _no_ _libquicktime_ _c
> > It caches information to reduce startup times. dlopen() 10 *.so files
> > and doing various function calls to get all the info stored in that file
> > takes some time ...
>
> Yeah but I _don't_ _need_ _no_ _libquicktime_ _codecs_, so avoiding to waste
> all that time can be done simply by not
On Thu, Jan 09, 2003 at 04:52:46PM +0100, Gerd Knorr wrote:
> > > Still speaking as a user, I'm not annoyed by a dotfile per program I
> > > use. I'm much more annoyed by all the useless dotfiles, created by
> > > programs that I run once, and never again, without even having saved a
> > > configur
On Sun, Jan 05, 2003 at 07:30:33PM +0100, Josip Rodin wrote:
> On Sun, Jan 05, 2003 at 01:08:45PM +0200, Lars Wirzenius wrote:
> > Still speaking as a user, I'm not annoyed by a dotfile per program I
> > use. I'm much more annoyed by all the useless dotfiles, created by
> > programs that I run once
ry for breaking threading .. i had no way of replying
to original.
-Original Message-
From: Ola Lundqvist [mailto:[EMAIL PROTECTED]
Sent: Wed 1/8/2003 2:33 PM
To:Vardhan Varma
Cc:
Subject: Re: Policy Suggestion - User Configuration Files
Hi
If I'm not mistaken you can send
g
> their home directory. One suggestion that came out of it that I liked
> was to put all the user configuration files under a sub directory such
> as ~/.etc. This way the user's home directory is left uncluttered and
> the structure more or less reflects that of the system-wide
>
On Sun, Jan 05, 2003 at 04:30:48AM +0100, Marco d'Itri wrote:
> Recent programs do not have user-editable configuration files anyway.
Parse error.
--
2. That which causes joy or happiness.
On Sun, Jan 05, 2003 at 01:08:45PM +0200, Lars Wirzenius wrote:
> Still speaking as a user, I'm not annoyed by a dotfile per program I
> use. I'm much more annoyed by all the useless dotfiles, created by
> programs that I run once, and never again, without even having saved a
> configuration, or do
On Sun, 2003-01-05 at 08:05, Sebastian Rittau wrote:
> (Evolution is bad enough by creating an "evolution" directory in my
> homne [...]
The reason it does this is because evolution's directory isn't just
configuration files; it also contains all your mail. Having your mail
hidden away in a . d
On Sun, Jan 05, 2003 at 01:08:45PM +0200, Lars Wirzenius wrote:
> su, 05-01-2003 kello 03:21, Jamin W. Collins kirjoitti:
> > So, what do you folks think? Would it be worth while to have a Debian
> > policy regarding the placement of user configuration files in a
> > configuration sub directory of
On Sun, Jan 05, 2003 at 02:37:07AM +, Julian Gilbey wrote:
> I like the idea. I vote for ~/etc, though, not ~/.etc; there's little
> point hiding this one directory name if it is going to contain all of
> the configuration data.
While the general idea of having all configuration files in one
su, 05-01-2003 kello 03:21, Jamin W. Collins kirjoitti:
> So, what do you folks think? Would it be worth while to have a Debian
> policy regarding the placement of user configuration files in a
> configuration sub directory of the user's home dir?
Speaking as a user, I'd hate this change. It woul
On Sun, 5 Jan 2003 05:30:46 -0500
David B Harris <[EMAIL PROTECTED]> wrote:
> As for you leaving Debian ... why do people always bring that out?
> Jeeze.
Just to clarify. One can assume that if Debian Policy starts mandating
things without merit and which cause our users problems, then users will
On Sun, 5 Jan 2003 03:28:40 +
Colin Watson <[EMAIL PROTECTED]> wrote:
> In other words, somebody will be told "that bug's fixed in the
> development version of this package upstream", so they go and try it
> out. But, hey presto, not only does it ignore the configuration set up
> while using th
On Sun, 5 Jan 2003 04:30:48 +0100
Marco d'Itri <[EMAIL PROTECTED]> wrote:
> >Maybe ask on the FHS list for comments, too?
> This is outside FHS-domain. But I think that a so big change from
> standard UNIX practice would be so stupid that if accepted I would
> probably leave debian.
It's been sta
On Sun, Jan 05, 2003 at 04:30:48AM +0100, Marco d'Itri wrote:
> This is outside FHS-domain.
I'm confused by this. How, is a file system policy outside the FHS?
> But I think that a so big change from standard UNIX practice would be
> so stupid that if accepted I would probably leave debian.
A
On Jan 05, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>Maybe ask on the FHS list for comments, too?
This is outside FHS-domain. But I think that a so big change from
standard UNIX practice would be so stupid that if accepted I would
probably leave debian.
Recent programs do not have user-editable c
; their home directory. One suggestion that came out of it that I liked
> was to put all the user configuration files under a sub directory such
> as ~/.etc. This way the user's home directory is left uncluttered and
> the structure more or less reflects that of the system-wide
>
ere which doesn't use it (yet), and it may well confuse users.
>
> Maybe ask on the FHS list for comments, too?
Looks like an identical suggestion was made there a few months ago:
http://sourceforge.net/mailarchive/message.php?msg_id=1791001
--
Jamin W. Collins
; their home directory. One suggestion that came out of it that I liked
> was to put all the user configuration files under a sub directory such
> as ~/.etc. This way the user's home directory is left uncluttered and
> the structure more or less reflects that of the system-wide
>
A while back, on one of my other lists, there was a discussion about
user configuration files for the program and where to put them. That
led to how frustrated many users were with the dot files just littering
their home directory. One suggestion that came out of it that I liked
was to put all
tarted, whereas policy
suggestions print "Starting xxx: xxxd" before the daemon is started,
then print the "." after the daemon has been successfully started (see
policy section 10.4)
IMO policy's suggested way of doing things is much better than the
current suggestion in dh
the faults of the current system, and
why you think usenet will solve those faults, your suggestion may be
taken more seriously.
The positive points to our current system is that all information is
currently located at one point: http://lists.debian.org. One can use
the archives for historica
This suggestion could probably be sent to a number of different
departments of Debian, but it is most likely a general policy decision
on how to support your product. I am recommending to several
distribution packagers that the newsgroup comp.os.linux.* could benefit
from a
Processing commands for [EMAIL PROTECTED]:
> merge 51116 51262
Bug#51116: Suggestion: Packages should carry a manpage
Bug#51262: Suggestion: Packages should carry a manpage
Merged 51116 51262.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Darren
(I fondly remember my second slackware install. I had found out enough the
first time around to know that the names of commands was key to learning
linux. Several of the core slackware packages listed all the commands in
them in their descriptions, and raced against the install to get the command
n
Joey Hess <[EMAIL PROTECTED]> writes:
> Chris Waters wrote:
> > I think people are becoming too ready to propose grand, sweeping
> > changes to policy in order to fix obscure, minor problems.
> I agree.
> > If you *really* want something in policy, I'd suggest: "the package
> > description shoul
Chris Waters wrote:
> I think people are becoming too ready to propose grand, sweeping
> changes to policy in order to fix obscure, minor problems.
I agree.
> If you *really* want something in policy, I'd suggest: "the package
> description should list the binaries (or at least, the main binary)
gt; > pccts in fact contains several binaries, but non is called pccts. The
> > > main binary is called antlr and has a good manpage.
> >
> > > My suggestion is now, that "man pccts" should either point to the
> > > main binaries manpage or
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.
Your message has been sent to the package maintainer(s):
Debian Policy List
If you wish to co
I (Brian Mays) wrote:
> > While I agree that it is probably a good idea for large packages, with
> > many binaries, to provide such a man page (in section 7, of course), it
> > makes no sense for packages in general. Personally, I think that such
> > policy would be a waste of our developers' tim
and found
> > pccts. After installation I tried "man pccts", but that failed.
> > /usr/doc/pccts doesn't contain examples, so how do I use the thing?
>
> > pccts in fact contains several binaries, but non is called pccts. The
> > main binary is called antlr and has
> From: Anthony Towns
> What's wrong with using README.Debian for this purpose, which is already
> in common use?
Probably nothing, except that it isn't used consistently.
Daniel
On Thu, Nov 25, 1999 at 10:17:43PM -0500, Brian Mays wrote:
> Besides, is it so difficult to do "dpkg -L pccts"? If you want a list
> of the binaries, then try "dpkg -L pccs | grep bin".
Yes, people should know about dpkg -L in their quest for package level
documentation.
Not only will it show y
On Thu, Nov 25, 1999 at 10:17:43PM -0500, Brian Mays wrote:
> > My suggestion is now, that "man pccts" should either point to the
> > main binaries manpage or show a page that gives a one-line description
> > of the binaries of the package or one that has just relevant
hat failed.
> /usr/doc/pccts doesn't contain examples, so how do I use the thing?
> pccts in fact contains several binaries, but non is called pccts. The
> main binary is called antlr and has a good manpage.
> My suggestion is now, that "man pccts" should either point t
iled.
/usr/doc/pccts doesn't contain examples, so how do I use the thing?
pccts in fact contains several binaries, but non is called pccts. The main
binary is called antlr and has a good manpage.
My suggestion is now, that "man pccts" should eigther point to the main
binarys manpage
1 - 100 of 146 matches
Mail list logo
