On Monday 28 April 2003 03:56, Pedro Salgueiro wrote:
> Hi.
> I'm making a deb package of a project that i'm working
> on, and I need to know if a deb package can copy
> something to a directory of a user's home. I have read
> somewhere that a debian package can not toucth on a
> user's home but I
On Thursday 06 February 2003 13:57, Josip Rodin wrote:
> >
> > However disks are cheap enough that it seems reasonable to ask people
> > doing development to go buy a big disk.
>
> IME it's not the disk space that's so much of an issue, it's the bandwidth!
> Having to get 5 MB (all devel. stuff in
On Friday 13 September 2002 11:05, Martin Michlmayr wrote:
> * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [2002-09-13 11:00]:
> > the discussion seemed to indicate that we felt the compatibility links
> > were no longer required.
> >
> > Is this the standin
I am aware that joeyh removed the code from debhelper to support the links and
the discussion seemed to indicate that we felt the compatibility links were
no longer required.
Is this the standing of policy as well? I find people wanting lintian to not
report the warning on their package howeve
On 13-Aug-2002 Colin Walters wrote:
> Well, are we basically in rough consensus about this now?
>
> Here's an updated patch which just makes the priority increase 20
> instead of 30.
>
sure.
>
>> (I still want to hear what Branden has to say about all of this, too.)
>
> I haven't firmly made up my mind yet.
>
> Can someone tell me what the relationship between WMSP, "netwm", and
> the EWMH spec is?
>
netwm is the name for the spec referred to in the original mail of this policy
pr
On 07-Aug-2002 Jérôme Marant wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
>
>>> Actually, I would do the contrary, because since it aims at supporting
>>> kde and gnome, it does not enhance your system but it rather bloat
On 07-Aug-2002 Jérôme Marant wrote:
> Colin Walters <[EMAIL PROTECTED]> writes:
>
>> Package: debian-policy
>> Severity: normal
>> Tags: patch
>>
>> The attached patch should speak for itself. This came about because
>> users would often install 'x-window-system' (installs twm) and 'gnome2'
>> (
On 06-Aug-2002 Colin Walters wrote:
> [ no need to CC me, I read -policy ]
>
> On Tue, 2002-08-06 at 15:55, Sean 'Shaleh' Perry wrote:
>
>> I think the real thing to say is GNOME, KDE, etc should not ask for
>> x-window-manager but netwm-window-manager.
&
>
> I'd like to hear some feedback from X experts on this, esp. Branden.
> I also think it would be good if Gnome had some sort of tropism for
> metacity/sawfish outside of the x-window-manager alternative, but
> that's somewhat orthogonal to this proposal.
>
> However, I have a gut feeling that
>
> Change the rules for all the Debian distribution because you find that
> 'command -v' is handy, seems quite excessive to me...
>
the problem is there is no better replacement for 'command -v'. And we do not
really need an exception -- every shell we have supports this. So the only way
a pe
>
> ... You must not remove these packages or your system may become
> totally broken and you may not even be able to use dpkg to put
> things back"
>
> I'm rather confused (wrt the understanding of the policy)... The
> two parts of this sentence do not deal necessary with the same
> concept. BTW
On 22-Feb-2002 Bill Allombert wrote:
> Hello,
>
> Policy 13.6 state that
>
> 13.6 Copyright information
>
> Every package must be accompanied by a verbatim copy of its copyright and
> distribution license in the file /usr/share/doc/package/copyright. This
> file
> must neither be compre
On 08-Feb-2002 Federico Di Gregorio wrote:
> hi,
>
> hi have python-psycopg be a fake package that depends on the right
> python-psycopg package (i provide psycopg packages for python 1.5, 2.1
> and 2.2.) lintian give me an error saying that the package should
> contain at least the copyright fil
On 28-Dec-2001 Chris Tillman wrote:
> First, a caveat: I'm not a dd, and have only been involved with Debian
> and Linux for around 8 months.
>
> That makes me uniquely qualified :-) to suggest some kind of
> standardization for online help be implemented in policy for console
> programs.
>
Thi
>
> No, you shouldn't check.
>
> It is not a bug if any kind of cvs command is in any kind of file. It is a
> bug if that command is called during an automated build of a package.
>
> Blind scanning for cvs is wrong.
>
absolutely. grepping for a word almost never gives me the right results.
On 17-Dec-2001 Gerhard Muntingh wrote:
> On Mon, Dec 17, 2001 at 10:38:35AM -0800, Sean 'Shaleh' Perry wrote:
>> slurps in Debian sources and builds off the network? Assuming constant
>> network
>> connectivity is absolute, pure evil.
>>
>
> I reme
On 17-Dec-2001 Joey Hess wrote:
> Sean 'Shaleh' Perry wrote:
>> > Ok. Should this be a lintian check? Test for cvs -d :pserver:...
>> > in the rules file?
>>
>> I can add it if I must. However I would like to trust our developers to not
>> be
&g
>
> Other checks can be build-dependencies of lynx, omt, ftp and other similar
> packages. Build dependencies of cvs is maybe a good check too. I've seen
> it before with other packages.
>
lync could theoretically be used to dump an html file as plain text during the
build. Silly, but possible
>
> Ok. Should this be a lintian check? Test for cvs -d :pserver:...
> in the rules file?
>
I can add it if I must. However I would like to trust our developers to not be
that silly (-:
Besides, it COULD be valid to do a cvs co via another make rule in the rules
file, as long as it is not call
On 17-Dec-2001 Ola Lundqvist wrote:
> Hi
>
> I have a question about build time dependencies for
> a package. The question was rized because I have now included
> (same way as java-common) imports from cvs.debian.org in
> the rules file. This means that to build the binary packages
> you have to
On 28-Nov-2001 Miquel van Smoorenburg wrote:
> According to Sean 'Shaleh' Perry:
>> > If I'm not mistaken that is not nessecary unless we plan to move
>> > all .deb archives over to .lsb too, which is not going to happen.
>> > Debian will stay Debia
On 28-Nov-2001 Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
>>Have you read the lsb? Debian can not at this time claim to support it. We
>>would have to rewrite not only our init scr
On 28-Nov-2001 Grant Bowman wrote:
> Hello,
>
> I see the FHS 2.1 (2.2 is the latest http://www.pathname.com/fhs/) is in
> the Debian-policy 3.5.6.0. I see no mention of LSB in policy 3.5.6
> aside from one small footnote. There's only one bug filed with
> debian-policy but it's about Mesa/G
> I'd much rather go with the maintainers' judgements than lintian's.
seeing as lintian is a rather stupid perl script and the maintainer isn't this
seems like a good bet (-:
>
> It concerns the fact that MAKEDEV is called from the postinst to create
> the required ISDN devices, without first asking the user for permission.
>
It does seem a bit odd. Most packages seem to ignore that piece of policy.
Only plausible rationale would be the "sysadmins are cranky and wa
> I disagree with this proposal on a number of grounds:
>
> 1) There is more than one implementation of libGL available in Debian;
> bumping one to standard would require choosing one.
> 2) If Xlib is optional, I would be hard pressed to believe that libGL
> should be standard.
> 3) Surely we can
> Does this change have a rationale (and if so, could it be included in a
> footnote), or should it be reverted?
>
The file is expected to be changed, which would trigger the 'get the new
version?' prompt. Trying to reduce those prompts seems like a good idea.
Not sure if that is the rationale
On 10-May-2001 Chris Waters wrote:
> I'd like to remind people that Menu policy says that icon images
> used in the Debian menu system should be no larger than 32x32.
> Unfortunately, people seem to be sticking in any old image they can
> find, these days.
>
> I've filed a couple of bug reports a
On 07-May-2001 Julian Gilbey wrote:
> Most init.d scripts are expected to support all of start, stop,
> etc. options. But there are a small number of scripts which are
> obvious exceptions to this rule: restart, reboot, single, mountall.sh
> and so on.
>
> It would be really nice to have a parag
>
> I'd prefer if people seconded the diff in #66023 :) and then we can refine
> that stuff further if necessary.
>
agreed, let's get this solved.
(Seconded).
> Bottom line, I think the short-term arguments against making debhelper
> build-essential are decent, but long-term is another matter.
>
my understanding of build-essential is that the package gives people an easy
way to have a system capable of compiling a C(++) program. There is nothing in
it
> Ain't gonna happen. It's been discussed before. The problem is that most
> debhelper Build-Depends actually need to be versioned[1], which won't
> work with build-essential.
>
problem is when following unstable, one sometimes has debhelper depends change
fairly often. No sense forcing the buil
On Sun, Apr 22, 2001 at 07:08:14PM +1000, Herbert Xu wrote:
> Richard Braakman <[EMAIL PROTECTED]> wrote:
> > On Sat, Apr 21, 2001 at 05:03:34PM -0700, Sean 'Shaleh' Perry wrote:
> >> It was elevated to see just how many people this affected. Almost no one
>
On Sat, Apr 21, 2001 at 06:47:08PM -0400, Itai Zukerman wrote:
> On Sat, 21 Apr 2001 13:36:36 -0700, Sean 'Shaleh' Perry <[EMAIL PROTECTED]>
> wrote:
> > I was recently mailed about lintian failing on UPX compressed binaries in
> > packages.
>
> How does
On Sun, Apr 22, 2001 at 12:11:12AM +0300, Richard Braakman wrote:
>
> Rules files rarely call strip directly, and when they do it
> is uncomfortable to add the long options for stripping those
> two sections. It doesn't makes much difference whether 99%
> or 100% of the binaries strip them, becau
On Sat, Apr 21, 2001 at 04:44:24PM -0400, Bob Hilliard wrote:
> gcc apparently creates sections `.note' and `.comment' when compiling
> binaries. Running either `strip' or the -s option to install does not
> remove these redundant sections. Lintian issues a warning
> `binary-has-unneeded-sec
I was recently mailed about lintian failing on UPX compressed binaries in
packages. UPX is a way to compress binaries on x86 machines in such a way that
they are self decompressing -- i.e. it is transparent to the user.
However, compressed binaries have their own issues. The binary will not be
s
On Sat, Apr 14, 2001 at 07:49:32PM +0200, Daniel Kobras wrote:
> On Sat, Apr 14, 2001 at 10:28:57AM -0700, Sean 'Shaleh' Perry wrote:
> > I maintain libnet this way, it only ships as a static lib. So I have a
> > libnet0-dev package. Someday I hope to have a s
On Sat, Apr 14, 2001 at 05:29:20PM +0200, Daniel Kobras wrote:
>
> I have prepared a package of libdv, a library to de- and encode digital
> video data, and noted that it violates current policy: The x86 version
> of the library contains optimized assembler routines that are not
> relocatable. The
On 11-Apr-2001 Julian Gilbey wrote:
> We don't really have any standard way of saying "you really should do
> this as it's a really good thing to do, but there's no requirement to
> do so (and hence not a reason to file bug reports)".
>
I thought we were using RFC definitions of must and should,
> What do people think of this idea? The only change it will require in
> policy is specifying "FHS version 2.1" in place of "FHS" when we
> discuss it. (Exact diff will be supplied if needed.)
>
We should definately document the version of any policy we follow -- LSB, FHS,
etc.
Do you have an
On 26-Mar-2001 Antti-Juhani Kaijanaho wrote:
> On 20010326T112130-0800, Sean 'Shaleh' Perry wrote:
>> I just received a bug because lintian does not know about the section
>> 'science'. Where is the canonical list of sections?
>
> Basically, the set
I just received a bug because lintian does not know about the section
'science'. Where is the canonical list of sections?
On 07-Mar-2001 Ben Collins wrote:
> On Wed, Mar 07, 2001 at 06:14:08PM +0100, Othmar Pasteka wrote:
>> hi,
>>
>> while packaging modlogan i have to use overrides because modlogan
>> uses shared objects for its plugin system which are not shared
>> libs. but since there has to be a shlibs file for
On Tue, Mar 06, 2001 at 10:38:53PM +, Colin Watson wrote:
>
> So - reassigning the lintian bug about this to policy.
>
> Am I right in taking from the above that /usr/${arch} is essentially a
> miniature mirror of the /usr filesystem? They certainly seem to have
> similar structures. Thus, /u
On 28-Feb-2001 Julian Gilbey wrote:
> On Sun, 25 Feb 2001, Julian Gilbey wrote:
>
>> Package: debian-policy
>> Version: 3.5.2.0
>> Severity: wishlist
>>
>> Policy should now require packages to specify build time dependencies
>> (i.e., packages which require ... MUST specify...)
>
> I just chec
>
> I would like to propose that the debian/rules file is allowed to be
> non-makefile. Any kind of a program that can do the required stuff can be a
> debian/rules file. We shouldn't prohibit it when someone e.g. writes a short
> shell script or another interpreted script, as long as it works.
>
>>
> Clarification here. Since libtool is Priority: optional... shouldn't
> packages that use it Build-depend on it? If so you can use that to
> determine libtool was used, therefore .la files should be shipped as
> well?
interesting ..
On 27-Feb-2001 Josip Rodin wrote:
> On Tue, Feb 27, 2001 at 10:21:44AM -0800, Sean 'Shaleh' Perry wrote:
>> what to do about shared objects that are not meant to be linked against,
>> i.e.
>> plugins?
>
> If a .so is not meant to be linked against and is not
There has not been a consensus on several issues I have raised here:
what to do about cross-compiler directories? Do they belong in /usr/${arch}?
what to do about shared objects that are not meant to be linked against, i.e.
plugins?
libtool .la files, how can lintian handle this well?
also, I
Since suidregister was removed, packages are now allowed to ship items with the
set[gs]id flag on. This is currently a lintian warning. I have considered
removing it (and bugs ask me to do so) however I am not sure it is the right
thing to do. The warning lets the developer know that they are sh
Package: debian-policy
Version: 3.5.2.0
Severity: normal
please refer to lintian bug 86710, it asks for lintian to check the syntax of
the Build-Depends field.
Specifically, [!i386 m68k] seems like it could be valid, but seems to not be.
The archs are also whitespace separated, some people are us
I can not find anything in the checklist about Build-Depends. I have been told
it was 3.2.x, is this accurate?
On 21-Feb-2001 Bob Hilliard wrote:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
>> Error (E:) -- violate a MUST
>> Warning (W:) -- violate a SHOULD
>> XXX (?:) -- a MAY is not followed
>
> There should be no Linti
>>
>> no, it tries to do this based on 2.x level MUST/SHOULD and the authors
>> beliefs
>> of severity. Has nothing to do with the sureness of the test.
>
> When did this change, then? Christian and I designed it the way Anthony
> described it.
>
Gecko did some, new checks added between him a
On Wed, Feb 21, 2001 at 12:39:08PM +1000, Anthony Towns wrote:
>
> > > E!: non-FHS-directory
> > > E-: missing-manpage
> > > E?: standards-version-uses-4-digits-not-3
> > when I rewrite lintian (started yesterday) the lintian messages will match
> > policy:
> > Error (E:) -- violate a MUST
>
On Wed, Feb 21, 2001 at 11:30:23AM +1000, Anthony Towns wrote:
>
> I'd encourage the lintian maintainer ( :) ) to automatically file "old
> standards version" bugs about such packages (of normal/minor/wishlist
> severity); and I'd definitely encourage the lintian maintainer to file
> serious bugs
On 20-Feb-2001 Sean 'Shaleh' Perry wrote:
> So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to
> /usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I
> check
> the changelog and this binary-any package has not been uplo
>
> And more serious: If you want to force the upgrade of the standards
> version you must file 579 RC bugs on these packages.
>
sounds like a plan to me. Many of these are either:
a) horribly out of date
b) simply forgot to change the number
On 20-Feb-2001 Matthew Vernon wrote:
> Sean 'Shaleh' Perry writes:
> > Anyone have comments on the idea that the only packages we should release
> are
> > ones that have a maintainer, not Debian QA?
>
> How about asking the QA team? I think that "packages
On 20-Feb-2001 Seth Arnold wrote:
> * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [010220 10:39]:
>> Anyone have comments on the idea that the only packages we should release
>> are
>> ones that have a maintainer, not Debian QA?
>
> In taking a quick list
So, I grabbed fmirror today because an admin friend suggested it. I cd'ed to
/usr/share/doc/fmirror and low and behold, no /usr/share/doc/fmirror. I check
the changelog and this binary-any package has not been uploaded in 2 years. It
is standards version 2.3.0.1, ICK!
So, perhaps we should drop
Anyone have comments on the idea that the only packages we should release are
ones that have a maintainer, not Debian QA?
On Sun, Feb 18, 2001 at 03:34:35AM +0100, Peter Palfrader wrote:
> | 2.4.2. Package relationships
> |
> |
> | Source packages should specify which binary packages they require to
>^^
> | be installed or not to be installed in order
I would greatly appreciate it if some of you would read the lintian bug list
and supply comments, either in favor of the suggestions or against. Some of
the open bugs need policy updates to fully fix in my opinion.
Also, now is the time to submit your own lintian requests and bugs. I am
preparin
bug #71581 asks that lintian complain about packages that fail to ship .la
files as policy 11.2 requires. I am not against this per se.
However, how am I to know that a package should ship a .la file? When policy
refers to libs needing libltdl does it mean they dynamically link it? So I
could u
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
but are also useful as standalone documentation should be installed under
/usr/share/
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
It should place a file with the name if the package
-- end quote
'if the' should be 'of the'.
-- quote
In the example above the system administrator can easily comment out a line
if he don't wants to start a specific daemon,
-- end
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
Usually this is major version number of the library.
-- end quote
'the major'.
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:32 PDT 2000 i686
Versi
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
saying that they require certain binary packages being installed
-- end quote
I think this should read 'having been installed'. Present, future and past
are being blurred in that sentence.
-- quote
the fields which declare dependen
On Sun, Feb 11, 2001 at 01:38:53PM +1000, Anthony Towns wrote:
>
> "Starting internet superserver: inetd" doesn't seem like vitally important
> information, nor something worth having a "[Press enter to continue]" for.
> OTOH, it still seems worth printing, as discussed some time ago.
>
> This se
Package: debian-policy
Version: 3.5.0.0
Severity: minor
-- quote
If a version the package is already installed, call
-- end quote
seems to be missing an 'of'.
-- quote
A directory will never be replaced by a symbolic links
-- end quote
links should singular
--quote
Any packages all of whose fil
Package: debian-policy
Version: 3.5.0.0
Severity: minor
6.5
In each case if an error occurs the actions in are general run backwards
-- end quote
not sure what the author meant here. I suspect 'in are' is transposed and
should 'are in'.
-- System Information
Debian Release: testing/unstable
Arc
Package: debian-policy
Version: 3.5.0.0
Severity: minor
6.1
They should be readable and executable to anyone, and not world-writable.
the package management system looks at the exit status from these scripts.
-- end quote
The second sentence should begin with a capital letter.
-- System Inform
Package: debian-policy
Version: 3.5.0.0
Severity: minor
5.2
It is important to understand that the DEB_*_ARCH string does only determine
which Debian architecture we build on resp. for.
-- end quote
The English of this sentence is very poor. 'does only determine' and expecially
'we build on resp.
Package: debian-policy
Version: 3.5.0.0
Severity: minor
5.2
Since an interactive debian/rules script makes it impossible to auto-compile
that package and also makes it hard for other people to reproduce the same
binary package, all required targets MUST be non-interactive. At a minimum,
required t
Package: debian-policy
Version: 3.5.0.0
Severity: minor
Chapter 4:
upstream-version
It is usually version number of the original (`upstream') package of which the
.deb file has been made, if this is applicable.
-- end quote
a) between usually and version a 'the' should be added
b) 'of which' sho
Package: debian-policy
Version: 3.5.0.0
Severity: normal
3.1:
When writing the control files for Debian packages you must read the Debian
policy manual in conjunction with the details below and the list of fields for
the particular file.
-- end quote
'must read the Debian policy manual', but I
Package: debian-policy
Version: 3.5.0.0
Severity: normal
3.2.1:
The use lowercase package names is strongly recommended
--end quote
perhaps an 'of' should be added?
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:3
>
> Anyway, I was wondering if this is something we want to discourage in
> policy, or if I'm just not thinking the same way as most maintainers
> (i.e. my premises are flawed).
>
>
as you say in this and later messages on the thread, it is important that
Debian have a way of knowing how buggy
Package: debian-policy
Version: 3.5.0.0
Severity: minor
telent-client Any package that provides a telnet client
telent-server Any package that provides a telnet server
in both cases it should read telnet.
As an aside, it would be REAL nice if this list could be moved to a mac
Package: debian-policy
Version: 3.5.0.0
Severity: minor
footnotes.html:Having a separate package allows one to nistall
^^^
should be install
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux geisha 2
lintian currently emits a tag for cross-compilers because they make a directory
in /usr's top level for TARGET i.e. /usr/m68k-linux.
The FHS states:
No large software packages should use a direct subdirectory under the
/usr hierarchy. An exception is made for the X Window System because of
consi
>
> (Good thing I just happened to have a package that uses undocumented.7
> lying around, eh? :-)
>
> Anyway, except for the additional info on the new tag, it's a one-line
> patch, so it should be pretty easy to add.
>
please see the BTS, Colin submitted a full patch plus testset. (Which is h
>
>> Since lintian reports the absence of a manpage as an error, maintainers
>> (specially new maintainer) proceed to install a link pointing to
>> undocumented.7 instead of actually providing a manpage.
>
> The previous lintian maintainer was considering the idea of making the
> use of undo
I was of the understanding that we would also have to notify the US of what is
on our site.
On Sat, Dec 23, 2000 at 03:25:41PM +1000, Anthony Towns wrote:
> On Fri, Dec 22, 2000 at 02:02:01PM -0800, Sean 'Shaleh' Perry wrote:
> > Package: debian-policy
> > Version: 3.2.1.0
> > Severity: normal
> >
> > preinst scripts are not mentioned anywhere
Package: debian-policy
Version: 3.2.1.0
Severity: normal
preinst scripts are not mentioned anywhere in policy and should be.
-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux geisha 2.2.18pre11 #1 SMP Mon Oct 2 17:40:32 PDT 2000 i686
Versions of packages debian-policy
>
> So you think it's easy to force users to generate a unique version number?
> How are you going to do that? If you make a debian developer pass a
> special arg, how are you going to keep users from using the same thing?
>
> Obviously it's not so easy, or it would already be done.
>
beyond th
>
> Good grief. This would require all non-rsync mirrors to redownload *ever*
> .deb in the newly released distribution in whole, and would require
> every user to redownload every package they've installed if they want to
> upgrade from foo-unstable to foo-stable. It'd also mean package signature
>
> Sorry, I'm not a Debian developer so honestly don't know all the policies or
> processes behind making debs. But, it seems clear to me that if you use the
> pkg+version+arch as your UUID then a change in the md5sum caused by adding a
> signature would not effect the "UUID" and therefore be mo
> Your UUID is the pkg+version+arch. From my viewpoint it's as simple as
> that. Maybe the official policy needs to be updated so that it is clear
> that any change to the binary packages, including just compile time changes,
> requires a version update? That way you could change your "sigs" as
On 29-Nov-2000 Ben Collins wrote:
> I'm proposing we add a new field to generated packages, and as part of
> Debian policy, make them required for Debian packages. It's all very
> simple, doesn't requuire any effort by the maintainers other than
> upgrading dpkg-dev, and poses little side-affects
On 29-Nov-2000 Wichert Akkerman wrote:
> Previously Sean 'Shaleh' Perry wrote:
>> we do not remove the copyright. it is still in the source. I fail to see
>> why
>> having 300 copies of the same file is needed.
>
> Reread my mail. Then realize that the GPL
>
> Lots of packages include the generic GNU install instructions, nobody uses
> them because they have installed a Debian package, but lots of packages
> include them.
>
I would file a bug whenever I found that to be true.
On 29-Nov-2000 Wichert Akkerman wrote:
> Package: debian-policy
>
> RMS just asked me if it was true that all our packages don't include
> the GPL, just a reference to it, since that is a violation of the
> GPL itself. In his words:
>
we do not remove the copyright. it is still in the source.
On 22-Nov-2000 Wichert Akkerman wrote:
> Previously Chris Waters wrote:
>> I think Wichert was wrong in this case. I don't think policy should
>> be in charge of every minor feature of the toolkit, especially not
>> optional features.
>
> How many times do I have to repeat that this is *NOT* a f
>
> This would require lots of changes to packages.
>
so we change lots of packages. Debian is being used by IS more and more these
days. At VA alone we have some 100+ Debian machines now. The current package
setup makes this a headache for updates. Being able to log output and ensure
that t
>
> The sorts of information which currently get displayed, but which don't
> get prompted for, are things like "Restarting internet superserver:
> inetd", or "Updating /etc/network/interfaces: succeeded".
>
> To me, those sorts of outputs seem useful and helpful, so I think policy
> should proba
1 - 100 of 124 matches
Mail list logo
