(While this relates to a specific package, I think my real question
is more policy related...)
Can a package install files (via the unpack or a package maintainer
script) in a user directory? (I'm not talking about something trn or
netscape that creates one or more "user-state" files when it is ru
On 20-Oct-98, 05:22 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> Maybe you are simply surprised by the fact that base-files recently
> changed from installing a default /root/.bash_profile to installing a
> default /root/.profile (which is slightly "more POSIX").
No, I just noticed because I
On 20-Oct-98, 11:48 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> The one exception is seeding files for root. Since /root is is
> already created by the base, and it may have special needs for
> startupo files (like, it needs to be way more secure), the files in
> /etc/skel are not used
On 22-Oct-98, 11:02 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Why don't you think root umask and root PATH are critical
> parts of system security? Oh, man, the explouts possible when these
> are not set to good values ...
Oh sure, you're right about that. I was thinking of it a diff
On 22-Oct-98, 05:21 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Oct 1998, Steve Greenland wrote:
>
> > Here are some problems with the current "solution":
> > 1. Who said that root's home dir is /root?
>
> The /etc/passwd file as
On 09-Nov-98, 11:07 (CST), Daniel Martin <[EMAIL PROTECTED]> wrote:
> I will repeat my suggestion (since when I first made it, it was in a
> parenthetical comment and I wasn't quite certain what I meant by it
> anyway) for a "List of fixed bugs" to be included either under
> /usr/doc// or at the v
t should be changed, a long time ago. I
guess it fell into the crack between policy maintainer policies.
I'll submit a bug to get this changed.
Steve Greenland
it's appropriate to build a new package, which just provides
the basic _infrastructure_ for the other packages and which manages
the shared configuration files. (Check out the `sgml-base' package as
an example.)
======
Steve Greenland
On 28-Nov-98, 23:01 (CST), Steve Greenland <[EMAIL PROTECTED]> wrote:
> d) the related packages have to depend on the core package,
> and use the provided program to make any modifications to the
> configuration file
Joey Hess pointed out that requi
In the final section of the policy-change doc, it talks about the stages
a proposal goes through in the BTS. The first stage is [PROPOSED], the
second is [AMMENDMENT]. However, I don't see a description of what
causes this transition. Is it simply that the proposal is seconded?
Steve
Hmmm, I admit to being somewhat puzzled. I don't expect comments on
everything I post. However, this was a hot topic in debian-policy a week
ago (as it is 2 or 3 times a year), and I (mis-?) perceived an interest
in cleaning it up. However, there has only been one comment, and no
seconds. Should I
On 03-Dec-98, 06:48 (CST), Richard Braakman <[EMAIL PROTECTED]> wrote:
> Raul Miller wrote:
> > Steve Greenland <[EMAIL PROTECTED]> wrote:
> > > New Version =
> > >
> > > If two
On 03-Dec-98, 18:21 (CST), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>
> Polcy is very confused about configuration file as opposed to
> conffile, and appears to use the terms inter changeably (I have
> copies of a large post I made to the policy list a few months ago).
>
> Clari
On 14-Jan-99, 08:03 (CST), Ian Jackson <[EMAIL PROTECTED]> wrote:
> Santiago Vila writes ("Bug#29770: Policy contradicts itself about
> /etc/aliases"):
> ...
> > Policy says:
> >
> > "A package may not modify a configuration file of another package."
>
> Why don't we change this to:
>
> A pa
On 24-Jan-99, 18:24 (CST), "M.C. Vernon" <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Jan 1999, Jules Bean wrote:
> > (What is the difference between debian-qa and debian-testing?)
>
> Testing is finding bugs. QA is fixing them. I'd be interested in this too.
While that is rather amusing description,
On 28-Jan-99, 09:13 (CST), John Goerzen <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 28, 1999 at 02:17:42PM +0100, Raphael Hertzog wrote:
>
> > I really don't like your idea. There are many packages with many bugs :
> > http://master.debian.org/~vincent/report-bybugnum.txt
> > And also many packages
On 17-Mar-99, 12:33 (CST), Ian Jackson <[EMAIL PROTECTED]> wrote:
> Ideas I have had so far are:
>Usual
>Common
>Better
>Good
>Useful
>Widespread
>Commended
Common. This has no more value judgement than the existing priorities,
and is fairly obviously between Standard
On 05-Apr-99, 05:52 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> These packages are cross-compilers and the paths they use are
> currently derived from the cross-compiler guidelines in gcc's INSTALL
> document (by just replacing /usr/local by /usr).
I tend to agree on with Santiago and Marti
On 17-Apr-99, 12:20 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
>
> Unless, of course, the default system $PATH has been changed, for whatever
> reason.
But if it was changed for a reason, then the scripts shouldn't override
it.
> What if I change the path? These scripts should work even if I
On 05-Apr-99, 08:46 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
>
> Proposal 4:
> ==
>
> *) We don't go any further until there are packages in the distribution
> left which use a hardcoded install-info's --infodir option.
> This means that if this does not already happen in slink, w
On 18-Apr-99, 07:54 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Does it hurt anything? I've yet to see anybody point out to me that it
> does.
Again: it requires that a lot of people make modifications to a lot
scripts. It then puts us in a position that if the standard root path
ever change
On 19-Apr-99, 02:26 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> Yes, it does require a lot of people to make modifications to a lot of
> scripts -- but it certainly doesn't require modifications again if the
> root path ever changes. Why? Because these script are appending what THEY
> need, ev
On 20-Apr-99, 01:05 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Apr 1999, Steve Greenland wrote:
> > And appending doesn't really help. If you assume that you can't trust
> > root's path, then you have to override it, or else you just trade
Agree with your general points, and second.
One comment, though (and I know this is not what you want, but it's
a small change :-)).
>Text - text oriented tools other than editors
[snip]
>Viewers - image viewers
Where would something like GhostView or an Acrobat r
On 27-May-99, 11:02 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> How exactly do you make a formal policy proposal? I had a look at the
> policy and couldn't find a chapter describing it. Is that in a
> different file?
>
http://www.debian.org/~srivasta/policy/ch3.html
Manoj, you might wa
On 28-May-99, 14:21 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> Thu, 27 May 1999, Branden Robinson wrote:
> > FACT 2: xlib6g depends on xfree86-common
> I was talking about your implicit statement:
>
> "xlib6g must have a Depends: field on xfree86-common".
>
> from which FACT 2 derives.
>
On 30-May-99, 07:37 (CDT), Peter Makholm <[EMAIL PROTECTED]> wrote:
>
> Somebody mentioned another upcomming and more complete proposal by
> Wichert Akkerman in this area.
>
> I would like to see Wicherts proposal before rushing this proposal
> throug. I also understanded Fabien such that this w
On 02-Jun-99, 06:22 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Policy states that programms should use $EDITOR if set and else use
> editor as the prefered editor, but why not just use sensible-editor?
>
> sensible-editor will behave as needed by the current policy, but is
> more flexib
On 02-Jun-99, 06:22 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Policy states that programms should use $EDITOR if set and else use
> editor as the prefered editor, but why not just use sensible-editor?
>
> sensible-editor will behave as needed by the current policy, but is
> more flexib
On 03-Jun-99, 09:26 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Maybe we could rename sensible-editor to editor. I just hate having
> two things make the same.
>
> editor could be removed and sensible-editor would be renamed to editor
> and call /etc/alternatives/editor when $EDITOR is
(I've rearranged a few of the quotes.)
On 03-Jun-99, 12:40 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Fri, 28 May 1999, Steve Greenland wrote:
> > Whether or not xlib6g *by itself* provides a "significant amount of
> > functionality" is up to the
On 31-May-99, 19:02 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
>
> Same question as emacs mini-policy. Whether it has the weight of
> policy is not the same as whether it is included directly in the
> policy document or not.
What's the real benefit of having it be policy? It's just the way
A few additional rules for your consideration:
- The data directory shouldn't be synced to debian releases, and ought
to be paralled to dists, not main/contrib/non-free.
(Since there are no executables, what's the benefit of syncing it, with
the presumed multiplying of size and hassle? If a
On 12-Jun-99, 00:35 (CDT), Adam Di Carlo <[EMAIL PROTECTED]> wrote:
> Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> > I like to consider the source code (.c files, etc) and it's transfer
> > encoding (.tar.gz) to be seperate. if you repack it, or recompress it, all
> > you are doing is changing th
On 14-Jun-99, 02:06 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jun 1999 at 12:22, Joseph Carter wrote about "Re: Editor and...":
> > #!/bin/bash
> > shopt -s execfail
> > exec ${VISUAL:-${EDITOR:-editor}} "$@"
>
> Yes, I saw this. But I didn't see, like the following two lines,
> s
On 14-Jun-99, 01:51 (CDT), Brock Rozen <[EMAIL PROTECTED]> wrote:
> One works under Debian, the other doesn't. While pico isn't part of
> Debian, there is a package available and I still use it. While that is of
> no interest to you, it makes a whole lot of a difference to me -- and
> since sensib
On 16-Jun-99, 07:08 (CDT), Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Steve Greenland <[EMAIL PROTECTED]> writes:
> > What's so hard about that? If
> > you want pico to be the system wide default (god forbid), set EDITOR in
> > /etc/profile and /etc/cshrc
On 19-Jun-99, 16:16 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> Well the alternative that has been brought up before is to make everything
> use a deeper tree (like Apps/Editors/Big/Emacsen), and have menu
> automatically collapse the tree to Apps/Editors on your system with 2 editors
> and kee
On 23-Jun-99, 16:56 (CDT), Chris Waters <[EMAIL PROTECTED]> wrote:
>
> The new proposal addresses this. It requires that the maintainer
> describe the situation wrt man pages in TODO.Debian.
This won't keep people from filing duplicate bugs, as it requires the
person to take a second step to ac
On 27-Jun-99, 10:00 (CDT), Marc Haber <[EMAIL PROTECTED]> wrote:
> Hi!
>
> /var/state isn't in the fsstnd, yet it exists on Debian slink. Is
> there a text available that states what belongs into /var/state vs.
> /var/lib ("application state information")?
>
/var/state was originally part of th
On 27-Jun-99, 15:53 (CDT), Marc Haber <[EMAIL PROTECTED]> wrote:
>
> So using /var/state is actually discouraged?
>
Since it is not mentioned in the current FHS 2.1 draft
(http://www.pathname.com/fhs/fhs-2.1-pre-02.tar.gz), and the description
of /var/lib seems to encompass the possible uses of
On 01-Jul-99, 09:17 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
>
> #29770: Policy should be clearer about conffiles and configuration
>files: conffiles are those listed in DEBIAN/conffiles;
>configuration files might not be listed. And packages should not
>be permitted to direct
On 30-Jun-99, 05:05 (CDT), joost witteveen <[EMAIL PROTECTED]> wrote:
> The real difference is that when a program P happens to be in
> a/b/c/d/P, then with the hints, that location may be relocated
> to a/b/d/c/P (with c and d exchanged). Many probably again really
> dislike that, but think about
On 04-Jul-99, 05:32 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
> Because Debian is the distribution, where the user can upgrade or keep
> every single package without any drawbacks.
^
Who says that? Agreed, users should not be forced to upgrade
u
package: debian-policy
version: 3.0.0.0
The configuration files section has long needed correction
and clarification. I propose we replace the existing section
(currently 4.7) with the following text. (I don't think I've
made any substantiative changes to actual policy, but I may
have shaded some
package: debian-policy
version: 3.0.0.0
(NOTE: This is not a repeat of of 'Bug#40766: [PROPOSED] Rewrite of
"Configuration files" section')
This proposal is to clean up the wording of several sections in the
document that discuss "conffiles" and "configuration files", as well
as a few other minor
On 05-Jul-99, 07:49 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
> On Sun, 04 Jul 1999, Steve Greenland wrote:
> > Agreed, users should not be forced to upgrade unnecessarily, nor
> > accross-the-board, and we should make that as painlesl *as
> > reasonably fe
On 05-Jul-99, 15:23 (CDT), Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
>
> Presumed that _all_ packages for _all_ architectures are FHS compliant
> at the moment we release 2.2. I fear, that this isn't possible if we
> want to release potato in the next half year.
>
> [and]
>
> I would prefer
Package: debian-policy
Version: 3.0.0.0
Severity: wishlist
Add the following section 5.4 as the next to last paragraph (i.e. before
the one beginning "Since the Debian base system...").
A program may also use the VISUAL environment variable determine
the user's choice of editor. If
On 11-Jul-99, 19:58 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote:
>
> 4.7.4. Sharing configuration files
> --
>
> Only packages that are tagged _conflicting_ with each other may
> specify the same file as `conffile'.
>
> A package may not modify
If I understand the proposal, I think I have a strong objection to
the names of the fields.
> 2) Summary
>
> My proposal is, in short, the following: Define six new fields for
> debian/control and specify their meaning. The six new fields are used
> only in .dsc files and in the first paragraph
On 15-Jul-99, 02:51 (CDT), Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 14, 1999 at 09:32:22PM -0500, Steve Greenland wrote:
> > I realize that these would be in the first stanza of the control
> > file, and therefore don't technically conflict w
On 17-Jul-99, 13:08 (CDT), Stefan Gybas <[EMAIL PROTECTED]> wrote:
> Hamish Moffatt wrote:
>
> > * the maintainer scripts should not alter the conffile of ANY package,
> > including the one the scripts belong to.
> >
> > * the program itself in the package may modify the conffiles of other
> >
On 17-Jul-99, 20:45 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > Note that a script that embeds configuration information (such as most
> > of the files in `/etc/init.d' and `/etc/cron.{hourly,weekly,monthly}')
> > is de-facto a configuration file and should be treated as suc
On 18-Jul-99, 14:43 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > I'm against saying that "every conffile is a configuration file" simply
> > because I don't want to lock out some other legitimate use of the
> > conffile mechanism.
>
> The very nature of the conffile mechanism seems to be t
On 19-Jul-99, 04:25 (CDT), Julian Gilbey <[EMAIL PROTECTED]> wrote:
> One other question about the proposal. Is it necessary for multiple
> packages which share a configuration file for one of them to specify
> it as a conffile? Maybe it is a configuration file which by nature
> cannot be a conf
On 19-Jul-99, 19:41 (CDT), Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
>
> The price is actually higher. Richard already pointed out some corrections
> to your proposal, which add complication.
>
> But the real expense is elsewhere. I wonder why this hasn't come up before,
> but here it is:
>
>
On 27-Jul-99, 14:50 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>
> Well, since the copyright holders have not been actively
> involved in the newest phase of the manual.Should I make it copyright
> Debian? the debian policy list? spi?
I'd be happy to see "Debian". "The Debian
On 27-Jul-99, 14:43 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> We would liek to think that fellow maintainers are total incompetents
> and can manage a simple symlink.
I hope there is a "not" missing from that sentence :-). Even if I did
think so about someone, I wouldn't *like* it.
On 28-Jul-99, 21:37 (CDT), Joseph Carter <[EMAIL PROTECTED]> wrote:
> And then there are the people who think that we should just say screw
> backwards compatibility and just move the directories without bothering
> with transition. Unfortunately many of them are already uploading
> packages, whi
On 01-Aug-99, 16:31 (CDT), Nicolás Lichtmaier <[EMAIL PROTECTED]> wrote:
> > 75%. http://kitenet.net/programs/debhelper/stats/
> > (A little out of date, hasn't been updated in a month, but it will soon..)
>
> It should be higher... the more packages uses debstd/debhelper, the less
> lines of co
On 02-Aug-99, 11:22 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
>
> Yes, I agree helper packages would help, but those who chose not to use a
> helper package should not be "punished" for that.
Please describe how they are being "punished". If I choose not to use
a tool (and there are many l
On 03-Aug-99, 11:56 (CDT), Kai Henningsen <[EMAIL PROTECTED]> wrote:
> I second this. BTW, where are the policy changing rules written down? I
> just looked and couldn't find them.
>
They're now in the debian-policy package, as
/usr/doc/debian-policy/proposal.*
The wording is weird, because i
On 05-Sep-99, 23:00 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Unless someone else volunteers, I could come up with a
> suggested language to be included in policy. It would be
> updated with Raul's suggestions about not making all current packages
> instantly buggy,
On 10-Sep-99, 08:04 (CDT), Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Raul suggested to mention core dumps, which is indeed a good idea.
> I extended this to give a general rationale for debugging symbols.
[*snip* of suggested wording]
While I don't feel a real strong objection, I
On 11-Sep-99, 19:44 (CDT), Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> > While I don't feel a real strong objection, I don't think this kind of
> > stuff (rationale) belongs in the standard. It's already wordy enough.
>
> Well, it is not without precedence. For a lot of things in the policy, we
wo paragraphs, how about:
Because '/usr/local' and its contents are for exclusive use of
the local administrator, a package must not rely on the presence
or absence of files or directories in '/usr/local' for normal
operation, although the presence or absen
at a package installed) must *not* have any bearing on
> the function or behavior of that package.
Well, if the presence of a directory (and files) affect the function,
then the lack of them also affects it -- but that's nitpicking, and I
think your version is probably clearer. Looks good
/var/lib/dpkg/status
Yech. What's wrong with 'dpkg -S /etc/profile'?
Of course, this won't find it if is managed by the maintainer scripts
rather than being a dpkg conffile, in which case you're stuck grepping
(or perling) /var/lib/dpkg/info/*.postinst
steveg
--
sue of right or wrong, only what is preferred for a
> majority, there is no such thing as a logical response to this sentence.
Ok, well I prefer that Emacs, at least, remain in standard. I believe it
is a common enough package that most users will want to at least look at
it, and if they don&
quot; hie
upgrades. It provides the offer to install it when the package name
changes (e.g. emacs19->emacs20). That's it. Just like every other new
package that is added. That doesn't strike me as a huge burden. If it
is, perhaps we need to stop adding packages.
Steve
--
Steve Greenla
in /var/state[1]. And I just realized
that if someone uses the new LOGDIR variable in checksecurity.conf,
setuid.changes won't be affected.)
Steve
[1] It's a joke, son.
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
y "use 'info foo' for
documentation on foo", but the upstream author is basically responsible
for the contents of their software.
The maintainer is providing a useful service by configuring and building
the software for Debian, the lack of a few manpages is certainly less
i
e
tools it needs, you're going to be stuck upgrading gcc et. al. anyway.
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
But a lot of packages have one or more "main" binaries that do have man
pages, and a few auxiliary binaries that don't. Or have decent output
from 'foo --help'. (Consider the state of dpkg's manpage for a long
time, until some kind souls got ambitious and contributed
want to double or triple the namespace collisions? We have a heirarchal
file system, let's use it.
sg
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
;t you remove log files, which are
completely auto generated?)
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
m questions is exactly what makes MS Windows a user disaster.
Exactly what is wrong with simply reading the man pages and then issuing
the commands that do the thing you want? You only have to read one:
dpkg (and not even the whole thing!). Once you've done that, you know
what packages are g
is what you need
to do to finish configuring (if necessary), here's a one-liner for each
major binary of the package, here's what to read to find out more (info
pages, man pages, web site, whatever).
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this
On 30-Jan-00, 08:53 (CST), Michael Stone <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 29, 2000 at 10:18:18PM -0600, Steve Greenland wrote:
> > I'd much rather have useful info in README.Debian: this is what you need
> > to do to finish configuring (if necessary), here's
ing a binary.
Well, I should hope so! A program without a binary is definitely an
"Important" bug!
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
On 30-Jan-00, 01:15 (CST), Brock Rozen <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jan 2000 at 22:14, Steve Greenland wrote about "Re: [RFD]:...":
> > No, "purge" means what it says in dpkg(8):
> >
> > purge The package is selected to be purged (i.e.
with.
Beyond this, I just think we'll have to agree to disagree: I'm hardly
the prime mover in Debian policy, if you convince a majority, then I'll
not object (much).
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
on't think *every* editor (even at the time) was on the list -- I think
we just used the ones most likely to be somebody's desired default. Of
course nano should be there: pico is popular, even if I never been able
to understand the appeal :-).
Steve "what do you mean, 'vi isn
in policy; it's a feature request
for the packaging system, and (proper) implementation would have zero
affect on other packages.
I second Joey's original proposal, without this addition.
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
opinions (I do!), and will at least read with
an open mind.
Steve Greenland
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
pgpdimyi65PUg.pgp
Description: PGP signature
inst"
produced two hits (libc6 and netbase), while lots call "start". Hmm,
lots also call start-stop-daemon directly.
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
-- no warning
message, no exit code. If you want to do this, you need to change (or
clarify) policy, and get all the maintainers to change their scripts.
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
On 29-Mar-00, 08:40 (CST), Santiago Vila <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Mar 2000, Julian Gilbey wrote:
> > In particular,
> > given the update-mime program, /etc/mailcap should obviously not be a
> > conffile. And as it is, the maintainer should change that -- but
> > changing policy isn
d that if they are putting packages into the forthcoming
release, they need to be reading the current policy document.)
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
127.0.0.1 localhost
and that it was so unlikely to change in the distribution that making it
conffile would do little harm.) (Or maybe /etc/hosts is a bad example of
what you intended...if so, please clarify.)
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
"Reply-To:" to such an address when conducting a Debian
related conversation, but putting it in policy seems a little strong.
(Of course, if the Debian mailservers started using ORBS or DUL...no,
bad Steve!).
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on m
On 24-Apr-00, 06:39 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
>
> When this was written, non-us was a mix of free and non-free software.
> This is no longer true in potato, so I propose to change that to:
>
> -
> [...]
> T
On 24-Apr-00, 06:43 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> Policy "3.9 Environment variables" says:
>
> [...]
>
>Furthermore, as /etc/profile is a configuration file of the bash
>package, no other package may put any environment variables or other
>commands into that file.
Debian policy requires that the upstream changelog be accessible as
/usr/share/doc//changelog.gz. Some (many?) authors use an
alternative name for their changelog, with "CHANGES" seeming to be the
most popular. What is the appropriate thing to do?
1. Copy to changelog and compress?
2a. Copy as CH
On 28-Apr-00, 04:10 (CDT), Anthony Towns wrote:
> Comments, seconds, changes, etc appreciated. (I am following this list,
> btw)
In general, I approve of the concept and the edits you've made.
As a matter of esthetics, I think around every occurrance of
"must", "should", and "may" is distracti
On 01-May-00, 00:38 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> Steve Greenland wrote:
> > Debian policy requires that the upstream changelog be accessible as
> > /usr/share/doc//changelog.gz. Some (many?) authors use an
> > alternative name for their changelog, with
On 02-May-00, 01:40 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> [w.r.t. preserving the names of upstream changelogs]
> The default would become -k if something about preserving names was
> added to policy.
>
> I don't think the name always has to be preserved, it seems that in some
> cases ther
On 05-May-00, 10:36 (CDT), Anthony Towns wrote:
> Maybe something more like:
>
> In this manual, the words *must*, *should* and *may*, and
> the adjectives *required*, *recommended* and *optional*, are
> used to distinguish the signifance of the various guidelines in
> De
On 14-May-00, 13:56 (CDT), Chris Waters <[EMAIL PROTECTED]> wrote:
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > But a package which Recommends: www-browser needs no standard
> > interface whatsoever, for example.
>
> I believe they all fit this template:
>
> command-line:
>
But a l
1 - 100 of 218 matches
Mail list logo
