On Thu, 3 Dec 1998, Julian Gilbey wrote:
On Fri, 20 Feb 1998, Christian Schwarz wrotee, while discussing the
proposed (and agreed upon) changes to dpkg-genchanges and dinstall to
make the closing of bugs etc. run more smoothly:
Another suggestion was to change the Maintainer: field to
On 28 Nov 1998, Manoj Srivastava wrote:
Since /etc/aliases is not a conf file belonging to any package
whatsoever, sectiosn 4.7 and 5.5 are not in conflict. I am closing
this report.
Please, read carefully the bug report. Policy says:
A package may not modify a configuration file of
On Sat, 28 Nov 1998, Wichert Akkerman wrote:
A while ago someone (Santiago iirc) filed a bugreport about packages
depending on other packages with a lower priority. This made me
wonder about allowed relations between packages. Reading the policy
document does not give any explicit demands.
Package: debian-policy
Version: 2.5.0.0
I have discovered a little inconsistency in the policy.
Section 5.5, Mail transport agents says:
/etc/aliases is the source file for the system mail aliases (e.g.,
postmaster, usenet, etc.)--it is the one which the sysadmin and
postinst scripts
Hi.
We have the shlibs mechanism for dependencies on shared libraries.
This allows a package to be compiled under libc5, libc6, or whatever libc,
and the right dependency info will be calculated automatically.
However, there are some packages having a hardcoded dependency on
libc6-dev, and it
On 30 Oct 1998, Manoj Srivastava wrote:
Native Debian packages (i.e., packages which have been written
especially for Debian) whose version numbers include dates should
always use the `-MM-DD' format.
James Troup pointed out some time ago that this probably breaks another
On Thu, 22 Oct 1998, Steve Greenland wrote:
In either case, get rid of the .bashrc. If root wants an example,
there's always /etc/skel. Heck, if you want to copy dot.profile and
dot.bashrc to /root, no problem. Just stop screwing with the files that
are actually used!
Well,
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 provided by base-passwd. If you modify root's home
dir, you break the base-passwd package, since root is a user who belong
to the
On Mon, 19 Oct 1998, Ian Jackson wrote:
Are the additional things I said in my last message about this
sufficient for you to clarify the policy ?
I think they are not sufficient.
Maybe I should propose an amendment to the current text.
--
3bfc2ca36032b30f1040093bfee1f3ea (a truly random
On 17 Oct 1998, Adam P. Harris wrote:
Santiago Vila [EMAIL PROTECTED] writes:
[...]
They are not just things that would be nice to have implemented
(wishlist). We really *need* to have them fixed in the near future.
Otherwise we will never move to FHS.
Woah there, one step at a time
Hi.
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).
I considered several ways to do this. Among them:
1. If ~/.bash_profile exists and ~/.profile does
( Sorry for replying so late, the old Subject was not very appealing :-)
On 23 Sep 1998, Manoj Srivastava wrote:
I suggest that the preferred source format of the
documentation be also available. This means that we also ship
texinfo, tex, and sgml versions of the documentation, as
On 20 Oct 1998, Manoj Srivastava wrote:
Santiago So shipping the .texi source will not be as easy as some
Santiago people think,
And not as hard as some people think either.
He, he, we are close to repeat the bash-essential discussion here ;-)
--
8460b24dc2ac9d46432ccd8965300fbe
On 20 Oct 1998, Manoj Srivastava wrote:
Santiago It seems to me that the general rule that source belongs to
Santiago the source package should apply here.
No. HTML is not a good format for printing. dvi files are not
quite as portable as one would like (due to font issues)
The
Ian,
before you propose a complete reorganization of our FTP archive to
comply with the GPL, please take a look at the SOURCES file in the GNU
operating system, version 0.2.
Some excerpts:
*---
Sources for binaries in GNU version
On Mon, 5 Oct 1998, Ian Jackson wrote:
Santiago Vila writes (Re: /etc/adjtime, /etc/timezone, etc.):
...
Of course it is possible. But the reason policy says some files should not
be conffiles is the following: Doing this will lead to dpkg giving the
user confusing and possibly dangerous
On 16 Oct 1998, Adam P. Harris wrote:
Santiago Vila [EMAIL PROTECTED] writes:
On 10 Oct 1998, Adam P. Harris wrote:
2. info browsers, manual pagers, terminfo libraries, etc., are
Yes, but where is the info program that looks in both directories?
Before saying this must be done
On Thu, 15 Oct 1998, Ian Jackson wrote:
We have discussed this before, but it seems that you missed the discussion
at all: If man and info are modified so that they support both old and new
locations, we will not have to symlink anything, and we will not need to
copy a lot of files from a
On 10 Oct 1998, Adam P. Harris wrote:
2. info browsers, manual pagers, terminfo libraries, etc., are
Yes, but where is the info program that looks in both directories?
Before saying this must be done in this way I would like to be sure that
effectively it may be done and someone will do it.
On Tue, 6 Oct 1998, Ian Jackson wrote:
(See also my post to debian-devel about this. In particular, I'm
opposed to /var/state and think we should ignore the FHS on this
point.)
One of the key changes that the FHS has compared to the FSSTND is the
existence of /usr/share. I think this is
On Tue, 29 Sep 1998, Herbert Xu wrote:
After purging emacs today, the damn thing deleted my /usr/local symlink since
it was the last package to have /usr/local in it. Obviously this is not very
clever.
Would have this happened if base-files contained /usr/local as an empty
directory?
Since
On Tue, 29 Sep 1998, Herbert Xu wrote:
On Tue, Sep 29, 1998 at 01:28:27PM +0200, Santiago Vila wrote:
On Tue, 29 Sep 1998, Herbert Xu wrote:
After purging emacs today, the damn thing deleted my /usr/local symlink
since
it was the last package to have /usr/local in it. Obviously
On 21 Sep 1998, Manoj Srivastava wrote:
- ship HTML versions in the binary package, in the directory
- /usr/doc/package or its subdirectories.
+ ship HTML versions in a binary package, under the directory
+ /usr/doc/appropriate package or its subdirectories.
I second this.
It
On Mon, 14 Sep 1998, Zed Pobre wrote:
+ this string is reserved for the GNU Hurd operating system.
GNU/Hurd
[ I think everyone will agree on this ].
Thanks.
--
60bd5544e9f94328d8d2823b5dc2452e (a truly random sig)
On Tue, 15 Sep 1998, Marcus Brinkmann wrote:
On Mon, Sep 14, 1998 at 10:00:36PM +0200, Santiago Vila wrote:
On Mon, 14 Sep 1998, Marcus Brinkmann wrote:
So should we change i386-hurd to i386-gnu on the ftp archive? This would
also express the explicit wish of Gordon, IIRC.
I
On Mon, 14 Sep 1998, Zed Pobre wrote:
In the mean time, then, if I understand correctly, the only arch
string that will allow proper compilation is i386-gnu?
Yes, because the gnumach kernel does only work under intel currently.
--
136b152ac3c4c1d999f0afddbbb9c284 (a truly random sig)
On Mon, 14 Sep 1998, Marcus Brinkmann wrote:
On Mon, Sep 14, 1998 at 05:24:25PM +0200, Santiago Vila wrote:
On Mon, 14 Sep 1998, Zed Pobre wrote:
In the mean time, then, if I understand correctly, the only arch
string that will allow proper compilation is i386-gnu?
Yes
On Sun, 13 Sep 1998, Richard Braakman wrote:
Zed Pobre wrote:
Part 3: (bug#25385)
Section 4.1 (Architecture specification strings) should be changed
to allow the Hurd operating system. This requires that the segment
reading:
where `arch' is one of the following: i386, alpha,
On 4 Sep 1998, Manoj Srivastava wrote:
Santiago But the reason policy says some files should not be
Santiago conffiles is the following: Doing this will lead to dpkg
Santiago giving the user confusing and possibly dangerous options
Santiago for conffile update when the package is
On 5 Sep 1998, Manoj Srivastava wrote:
Do you not find the version numbers suggestive?
debian-policy_2.4.1.3.deb
developers-reference_2.4.1.3.deb
packaging-manual_2.4.1.1.deb
Would there be serious objections to having the policy
maintainers actually take
Ok, I will answer myself :-)
I have found a paragraph in the packaging manual providing the rationale
for not making conffiles certain files. However, the given rationale is
not enough when the conffile is always the same, so I have just submitted
a bug against debian-policy asking for more
(thanks for answering :-)
On 4 Sep 1998, Manoj Srivastava wrote:
Santiago Ok, I will answer myself :-) I have found a paragraph in
Santiago the packaging manual providing the rationale for not making
Santiago conffiles certain files. However, the given rationale is
Santiago not enough
[ Please don't Cc:me, I will read your input in the list ]
Hi.
In bug #23255, Nicolás Lichtmaier reports that /etc/adjtime should
probably not be a conffile (i.e. a configuration file managed by dpkg
through the conffile mechanism), and he cites policy to support this.
However, since the
On 20 Aug 1998, Martin Mitchell wrote:
Santiago Vila [EMAIL PROTECTED] writes:
Therefore, I will send the last proposal:
http://www.debian.org/Lists-Archives/debian-policy-9808/msg00115.html
to [EMAIL PROTECTED], so that whenever the new upload procedure is
implemented, the list
On 20 Aug 1998, Martin Mitchell wrote:
I suggest that the current debian-devel-changes be your
debian-devel-changes-source list, because I think most of the people
currently subscribed to debian-devel-changes are developers, more
interested in new releases (ie source packages) than binaries.
On 20 Aug 1998, Manoj Srivastava wrote:
Hi,
Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago Maybe the right thing to do here, since none of the new
Santiago lists did exist previously, and since debian-devel-changes
Santiago will disappear as such, is to let people
On Wed, 19 Aug 1998, Wichert Akkerman wrote:
Previously Santiago Vila wrote:
If I don't hear any serious objection, I will send the proposal to
[EMAIL PROTECTED], [.. snip snip ..]
Could you first take a look at all comments made and post a new proposal?
If I remember correctly some nice
Splitting of debian-devel-changes
=
I'm going to summarize everything so far:
* The list may be filtered in many several ways, but this does not solve
the problem of bandwidth for people using POP (the too late problem).
Therefore, most people seem to agree that
Hi.
Seven days ago, I posted my second proposal for the splitting of
debian-devel-changes.
If I don't hear any serious objection, I will send the proposal to
[EMAIL PROTECTED], where is the bug which asked for the new upload
procedure, so that whenever the new upload procedure is
On 17 Aug 1998, Manoj Srivastava wrote:
The GPL, LGPL, BSD, and Artistic licenses do not apply to any
software specifically, and can be considered stand alone. (If I am
wrong, please point out wording in the license that specifies which
package or specific software the license
On 16 Aug 1998, Manoj Srivastava wrote:
Marcus Brinkmann [EMAIL PROTECTED] writes:
We ship software with a copyright attached to it.
On the contrary. Look at what ships /usr/doc/copyright/GPL.
The package base-files ships the licenses un attached to software. [...]
Yes, but we ship
On 16 Aug 1998, Manoj Srivastava wrote:
Shipping the GPL as part of the package is the exception
rather than the rule. and /usr/doc/copyright/GPL is a shipped
standalone.
Shipping the GPL as part of the *source* package is the rule.
Since we have lots of GPLed packages it would be
-BEGIN PGP SIGNED MESSAGE-
Ok, second proposal:
The distributed, non i386-centric one:
The debian-devel-changes is renamed to debian-devel-changes-i386, and an
announcement is sent explaining the goal of the new list.
There would be the following lists:
a) debian-devel-changes-arch
-BEGIN PGP SIGNED MESSAGE-
On 29 Jul 1998 [EMAIL PROTECTED] wrote:
[...]
Then we can localize an internationalized package. For many languages
And everybody agrees that there is no reason to keep in one package
all localized versions.
I disagree. The FSF also disagrees. All GNU
-BEGIN PGP SIGNED MESSAGE-
Marco Budde:
SV I have received a suggestion for debstd, namely, to not compress
SV any *.db files found in /usr/doc/package by default.
No, I've suggested to compress only know file types instead of
compressing everything.
Yes, and I think that the
-BEGIN PGP SIGNED MESSAGE-
Hi.
I have received a suggestion for debstd, namely, to not compress
any *.db files found in /usr/doc/package by default.
I'm in doubt about this change.
Is not compressing *.db files in /usr/doc/package reasonable
as default behaviour?
Would debhelper
-BEGIN PGP SIGNED MESSAGE-
Rob Tillotson wrote:
[...] Since this emacs does not follow the new packaging conventions for
emacsen, it is incorrect for new-emacsen packages to depend on emacs
as that will cause the installation to break. (Which is exactly what
the packaging system is
-BEGIN PGP SIGNED MESSAGE-
On 11 Jun 1998, Rob Tillotson wrote:
Would not have been easier to keep the name emacs for emacs19, but
allowing other packages also to provide emacs?
No, because the old emacs doesn't provide the same capabilities as
what is now called emacsen,
The
-BEGIN PGP SIGNED MESSAGE-
On 31 May 1998, Karl M. Hegbloom wrote:
Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago Mmm, do you mean, for example, that /etc/init.d/*
Santiago scripts are not configuration files, because they are
Santiago actually scripts
-BEGIN PGP SIGNED MESSAGE-
On 31 May 1998, Karl M. Hegbloom wrote:
Kai /var/list/.bin/mimencap.local /var/list/.etc/archive.txt
Kai /var/list/.etc/help.txt /var/list/.etc/rc.archive
Kai /var/list/.etc/rc.custom /var/list/.etc/rc.main
Kai /var/list/.etc/rc.post
-BEGIN PGP SIGNED MESSAGE-
On 2 May 1998, Manoj Srivastava wrote:
Packages only have to specify the first three digits of the
version number in the `Standards-Version' field of their source
packages.
only three is three.
I fully agree with Martin in that if 'at least 3' was
-BEGIN PGP SIGNED MESSAGE-
On Wed, 15 Apr 1998, Ian Jackson wrote:
I mean that just because X is a conffile doesn't necessarily imply
that X is a configuration file, or vice versa.
Could you please tell us some examples of conffiles not being
configuration files, just to make it
-BEGIN PGP SIGNED MESSAGE-
On Mon, 13 Apr 1998 [EMAIL PROTECTED] wrote:
Could all of you reading this review bug #17532? Question: what severity
should it actually be?
In the bug report, you said:
this bug has prevented ALL logins (possibly including
single-user/maintaince mode;
-BEGIN PGP SIGNED MESSAGE-
On Tue, 7 Apr 1998, Ian Jackson wrote:
I also propose the following guidelines for determining whether a bug
report should be kept open, etc. These may be stated elsewhere
already, but should be consolidated:
[snipped]
I mostly agree.
Could we please
-BEGIN PGP SIGNED MESSAGE-
Manoj is right. Rewording:
Are there any objections to the policy proposed by Ian?
I would like to see approved (by the usual procedures) a policy with
respect to bug reports as soon as possible, because we have no policy at
all so far (only current practice).
-BEGIN PGP SIGNED MESSAGE-
Manoj Srivastava wrote:
In the specific dispute you are involved in, the letter of
this proposed policy has already been followed.
In short, I would summarize my old bug as follows:
1) A .m file in the future (or a computer in the past) causes octave
-BEGIN PGP SIGNED MESSAGE-
On Tue, 7 Apr 1998, Ian Jackson wrote:
1. Santiago initially mailed [EMAIL PROTECTED] about this matter, and didn't
go away when Guy told him to. He did when I referred him here. (At
this point neither Guy nor I entered into the details of the
situation,
-BEGIN PGP SIGNED MESSAGE-
On Wed, 8 Apr 1998, Ian Jackson wrote:
I hadn't realised that developers wouldn't know that there would be a
better way for them to sort this kind of thing out.
Do I need to add some text saying
`If you are a Debian developer, please use our internal
-BEGIN PGP SIGNED MESSAGE-
On Wed, 8 Apr 1998, Ian Jackson wrote:
`X is a conffile' =/= `X is a configuration file'
Mmm, do you mean, for example, that /etc/init.d/* scripts are not
configuration files, because they are actually scripts (i.e. programs, not
files that contain data)?
-BEGIN PGP SIGNED MESSAGE-
I have a great difficulty in convincing the Debian octave maintainer that
Bug #20561 is a bug. I have explained him in great detail why it is a bug
but he still says it is not and even *refuses* to discuss about it.
May I also close all my bugs by saying they
-BEGIN PGP SIGNED MESSAGE-
On Tue, 7 Apr 1998, Ian Jackson wrote:
2. There are two issues being confused here. One is the behaviour of
with respect to files in the future, and the other is the search path
ordering. There should be two bug reports.
Dirk also thinks I'm confusing two
-BEGIN PGP SIGNED MESSAGE-
On Tue, 7 Apr 1998, Ian Jackson wrote:
4. Noone but the maintainer of a package (or someone acting on their
request) should close its bug reports.
We could be flexible here, in some cases:
For example, if someone submits a bug, and just after sending the
-BEGIN PGP SIGNED MESSAGE-
On Tue, 7 Apr 1998, Anthony Towns wrote:
What I'd like to propose, therefore, is extending the conffile label
to cover all configuration files.
Why do you want to do that?
Why should I want to be asked each time I upgrade the system because of
local files
-BEGIN PGP SIGNED MESSAGE-
Well, if /bin/ps is not essential to the system, why it is in /bin?
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
iQCVAgUBNRgQfiqK7IlOjMLFAQFMlQP/eSQNds3w/1JjznI/YWEq8vRJgBcljPtX
UVE+L2oNiWRrLRi8eDQ6mJ+7naqVBr7sMpeNvRXujEik9WgVoCfHc/yopUjJ6bVi
-BEGIN PGP SIGNED MESSAGE-
Fine.
Summary: Either
1) procps is(should be) essential. or
2) procps is not(should not be) essential.
If 1), I would propose to add Pre-Depends fields for libc6.
If 2), then someone should report a bug against netbase for using
ps in the postinst without
-BEGIN PGP SIGNED MESSAGE-
On Mon, 23 Mar 1998, Ian Jackson wrote:
3. ncurses-bin contains clear and reset, among others. If this
package is essential, then those commands are allowed to be used in
maintainer scripts.
I think I disagree with `if this package ... scripts'. It
-BEGIN PGP SIGNED MESSAGE-
On 23 Mar 1998, James Troup wrote:
I can't see any reason for ncurses-bin to be essential.
Well, I can see a reason: if the console is so messed up that you don't
even see dpkg when you write it, and you have not clear or reset, then
you have a problem.
-BEGIN PGP SIGNED MESSAGE-
James Troup writes:
Santiago Vila [EMAIL PROTECTED] writes:
I can't see any reason for ncurses-bin to be essential.
Well, I can see a reason: if the console is so messed up that you
don't even see dpkg when you write it, and you have not clear
-BEGIN PGP SIGNED MESSAGE-
On 23 Mar 1998, James Troup wrote:
Santiago Vila [EMAIL PROTECTED] writes:
That's not enough reason to make a package Essential, the policy
manual clearly states that removing a required package can leave
your system totally FUBAR
-BEGIN PGP SIGNED MESSAGE-
On Fri, 20 Mar 1998, Ian Jackson wrote:
Santiago Vila writes (Re: Proposal how to handle mass bug reports):
...
Mmm, well, what if I sent just one bug against ftp.debian.org saying
these 100 packages should not have `optional' priority but `extra'?
I
-BEGIN PGP SIGNED MESSAGE-
On Fri, 20 Mar 1998, Ian Jackson wrote:
I'm sorry, what precise policy change is being proposed ?
It is currently policy that Essential packages have to use Pre-Depends
for things which they need to support the packaging system. They
should use Depends,
-BEGIN PGP SIGNED MESSAGE-
On Fri, 20 Mar 1998, Ian Jackson wrote:
Santiago Vila writes (Re: need input: essential packages and pre-depends):
...
For example, if diff is essential, it should Pre-Depends on libc6, because
otherwise maintainer scripts which use it would fail. Right
-BEGIN PGP SIGNED MESSAGE-
On Wed, 18 Mar 1998, Ian Jackson wrote:
Noone may submit many bug reports or send mail to many maintainers
without prior approval for the specific person in question to send
mail under those specific circumstances.
Even for violation by packages of an
-BEGIN PGP SIGNED MESSAGE-
On Tue, 17 Mar 1998, Marcelo E. Magallon wrote:
On 16 Mar 1998, Ben Gertzfield wrote:
Do I remove the newer libtool from the upstream source and replace
it with the current libtool in the Debian distribution?
add libtoolize --force --copy to
-BEGIN PGP SIGNED MESSAGE-
On Thu, 12 Mar 1998, Luis Francisco Gonzalez wrote:
For example, for german, all programs seem to use
/usr/share/locale/de/LC_MESSAGES/name but unfortunately, unless you define
LC_ALL=de rather than say LC_ALL=de_DE, this path is not searched
-BEGIN PGP SIGNED MESSAGE-
file-directly-in-usr-share
Hi Christian.
It seems this tag is a little bit confusing.
Would be possible to find a better one? For example:
file-directly-in-usr-share-not-in-a-usr-share-directory
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset:
-BEGIN PGP SIGNED MESSAGE-
On Sat, 7 Mar 1998, Yann Dirson wrote:
But I do agree it would be nice to have a special syntax for version
numbers allowing to cope with {pre,alpha,beta}-like numbering. It is
perfectly sane to distinguish between it's in testing stage and
it's released
-BEGIN PGP SIGNED MESSAGE-
On 6 Mar 1998, Manoj Srivastava wrote:
Herbert Yes but unless you actually require any non-POSIX features,
Herbert you should use /bin/sh (this is specified by the policy).
Herbert And currently I don't see anything like that in your scripts.
Where?
-BEGIN PGP SIGNED MESSAGE-
On 7 Mar 1998, Manoj Srivastava wrote:
using /bin/sh is just waiting for a problem to occur,
Oh, yes, removing the /usr/spool symlink is also waiting for a problem to
occur...
That argument does not convince me at all.
-BEGIN PGP SIGNATURE-
Version:
-BEGIN PGP SIGNED MESSAGE-
On 7 Mar 1998, Manoj Srivastava wrote:
Anyway, bash is essential, /bin/bash shall always be there,
using /bin/bash shall never cause any problems,
That argument is also not convincing at all.
If you really believe what you are saying, then please
-BEGIN PGP SIGNED MESSAGE-
On Fri, 6 Mar 1998, Yann Dirson wrote:
Package: lintian
Version: 0.3.0
E: e2fslibsg-dev: symlink-should-be-absolute usr/lib/libe2p.so
../../lib/libe2p.so.2.3
N:
N: Symbolic links into /etc or /var should be absolute.
N:
N: Refer to Policy Manual,
-BEGIN PGP SIGNED MESSAGE-
On Tue, 3 Mar 1998, Christian Hudon wrote:
On Tuesday, March 03, Dale Scheetz wrote
Format: 1.5
Date: Sun, 1 Mar 1998 19:02:48 -0500
Source: glibc
Binary: timezones libc6 libc6-pic libc6-dbg locales libc6-doc libc6-dev
Architecture: source i386
-BEGIN PGP SIGNED MESSAGE-
On 25 Feb 1998, James Troup wrote:
Joey Hess [EMAIL PROTECTED] writes:
Anyway, I think this is a bug in dpkg (not asking about removed
conffiles) and I don't think it is right to make a program to
benefit from bugs in other programs...
I've
-BEGIN PGP SIGNED MESSAGE-
On 24 Feb 1998, Manoj Srivastava wrote:
There is no need for conffiles in /root; I'd be happy to
provide patches to the postinst if the maintainer feels unsure about
coding it.
I mostly agree. Current base-files_1.7.postinst now says:
#!/bin/sh
-BEGIN PGP SIGNED MESSAGE-
On 25 Feb 1998, Manoj Srivastava wrote:
the default files are puerile [...]
If you must have these files to copy into /root, keep them in
/usr/lib/basefiles (which is not in the root partition) [...]
Mmm, should I create a subdirectory in /usr/lib
-BEGIN PGP SIGNED MESSAGE-
On Wed, 25 Feb 1998, Joey Hess wrote:
Manoj Srivastava wrote:
Compared to that, the default files are puerile. It is
annoying to have little control over my home directory as root, and
b) have to delete those files over and over again since they
-BEGIN PGP SIGNED MESSAGE-
On Thu, 19 Feb 1998, Gregor Hoffleit wrote:
perl5 installs its modules that are AFAIK architecture-independent
into /usr/lib/perl5. Shouldn't this be /usr/share/perl5 according to
FSSTND?
No according to FSSTND. But yes according to the FHS.
We are not
-BEGIN PGP SIGNED MESSAGE-
We should remember that dpkg *does* allow a package to be installed
when the *Dependencies* are not satisfied.
Example. In a pure bo system, the following may happen:
# dpkg -i diff_2.7-15.deb
[ This is the diff from hamm ]
(Reading database ... 15191 files
-BEGIN PGP SIGNED MESSAGE-
On 18 Feb 1998, James Troup wrote:
Santiago Vila [EMAIL PROTECTED] writes:
[ ... ]
Perhaps we should just make mawk and gawk to Pre-Depend on libc6
instead?
With all due respect, you've 100% missed the point of making awk an
essential package
-BEGIN PGP SIGNED MESSAGE-
On Tue, 17 Feb 1998, Christian Schwarz wrote:
On 16 Feb 1998, Manoj Srivastava wrote:
I must admit I didn't notice this discussion until I saw the discussion
about the bug reports on this topic. Could someone please explain in a few
sentences the
-BEGIN PGP SIGNED MESSAGE-
On Mon, 9 Feb 1998, Christian Schwarz wrote:
Santiago (base-files maintainer) pointed out that the current base-files
package depends on the virtual package `awk' which makes awk `implicitely'
essential.
(With that it is guaranteed, that _some_ awk
-BEGIN PGP SIGNED MESSAGE-
[ moving to debian-policy ]
On 16 Feb 1998, Manoj Srivastava wrote:
Santiago Package A depends on library C, package B uses A in the
Santiago preinst script. A is essential. We issue the following
Santiago command:
Santiago dpkg -i A.deb B.deb C.deb
-BEGIN PGP SIGNED MESSAGE-
On 16 Feb 1998, Manoj Srivastava wrote:
The only bug is that the base-files maintainer dropped the
depends line without understanding the consequences.
The base-files maintainer asked Christian about the issue, who then asked
in debian-policy, and
-BEGIN PGP SIGNED MESSAGE-
On Fri, 13 Feb 1998, Scott Ellis wrote:
On Fri, 13 Feb 1998, Christian Schwarz wrote:
With the new lintian check I discovered that some packages install a `du'
control file (contains the output of the du command).
Does someone know which program is
-BEGIN PGP SIGNED MESSAGE-
On 13 Feb 1998, Davide G. M. Salvetti wrote:
They are useful to check how much disk space is needed under each
directory before installing a package;
Are you *so* short of disk space that the standard head:
Installed-Size: 200
is not enough?
-BEGIN
-BEGIN PGP SIGNED MESSAGE-
On Mon, 9 Feb 1998, Remco Blaakmeer wrote:
On Mon, 9 Feb 1998, Santiago Vila wrote:
Is there any Debian package that actually uses /var/preserve?
No, but according FSSTND 1.2, vi, ex and their clones (should) use it to
store temorary files that should
-BEGIN PGP SIGNED MESSAGE-
On Tue, 3 Feb 1998, G John Lapeyre wrote:
Where can I put a package that is not dangerous, and is
functional, but is still in early stages of development?
What about `experimental'?
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1
-BEGIN PGP SIGNED MESSAGE-
On Mon, 2 Feb 1998, Christian Schwarz wrote:
Is the following solution correct?
1. The `conffile' is _not_ tagged as conffile and _not_ included in the
package tree,
2. it's created in the postinst script if that file does not already
exist,
3. it's
-BEGIN PGP SIGNED MESSAGE-
On Mon, 26 Jan 1998, Christian Schwarz wrote:
Yes. Beta software is ok for unstable. Only critical software (i.e.,
programs that are likely to trash your filesystem) should go into
experimental.
I disagree here.
If beta is not ok for stable, then it is not
-BEGIN PGP SIGNED MESSAGE-
On Mon, 2 Feb 1998, I wrote:
``[...] It is almost certain that any file in /etc that is in your
package's filesystem archive should be listed in dpkg's conffiles control
area file. (See the Debian Packaging Manual).
It is almost certain that any file
301 - 400 of 430 matches
Mail list logo
