Chris Waters wrote:
> Also, this would rely on "debian/rules clean" completely reversing the
> effect of a build, and I can tell you right now, this was not true of
> *any* package I have adopted, and is still not true of at least one
> package I'm currently maintaining (haven't had time, plus ther
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
[SNIP]
Chris> The sysadmin is really supposed to stick to /usr/local and
Chris> /etc (and maybe /opt). I have to admit that I've been
Chris> seriously tempted to just silently del
On Thu, 28 Oct 1999, Julian Gilbey wrote:
> Any progress on this, by any chance?
I didn't hear from Miquel...
But I think, that your adaption in debian-policy 3.1.0pre1 is okay.
> There was a suggested implementation in the bug report; should that
> go in policy as a footnote?
I think this will
On Tue, Oct 26, 1999 at 11:02:29PM -0700, Joey Hess wrote:
> Permit/require use of bz2 for source packages (#39299)
> * Under discussion.
> * Proposed on 10 Jun 1999 by Chris Lawrence; seconded by Goswin
> Brederlow, Josip Rodin and Josip Rodin.
^^^
Roman Hodek <[EMAIL PROTECTED]> writes:
>The problem with this: Currently the .dsc is built before
>compiling, and thus the Build-* fields have to be known before
>dpkg-shlibdeps is run. But there's an easy solution (IMHO): Why
>don't we build the source package after the binaries?
Manoj Srivastava wrote:
> I think, then, there are a few things that should be moved
> from the packaging to the policy manual.
Agreed. But I think we should not rush this, and should go through the
normal amendment process for these, with the only difference being we
already have the tex
Any progress on this, by any chance? There was a suggested
implementation in the bug report; should that go in policy as a
footnote?
Julian
> On Mon, 25 Oct 1999, Julian Gilbey wrote:
>
> > I am about to include this amendment in policy. However, I am stuck
> > with the wording, as you say
On Thu, 28 Oct 1999, Darren O. Benham wrote:
> > + There must be a manual page at least for every program. If
> > + no manual page is available, this is considered as a bug and
> > + should be reported to the bug tracking system (the
> > + maintainer of the package is allowed to d
> Package: debian-policy
> Version: 3.0.1.1
> Severity: normal
>
> The docs contained in /usr/doc/debian-policy state that docs should go
> in /usr/share/doc/.
>
> If any package should comply with policy, it's debian-policy!
True, but the Project Leader asked us to wait with the /usr/doc ->
/us
On Thu, Oct 28, 1999 at 04:26:50PM +0200, Roland Rosenfeld wrote:
> severity 39830 normal
> retitle 39830 [AMENDMENT 28/10/1999] get rid of undocumented(7) symlinks
> thanks
>
> I proposed to change the "Manual pages" section of our policy to get
> rid of the undocumented(7) symlinks.
>
> This pr
Processing commands for [EMAIL PROTECTED]:
> severity 39830 normal
Bug#39830: debian-policy: [PROPOSED]: get rid of undocumented(7) symlinks
Severity set to `normal'.
> retitle 39830 [AMENDMENT 28/10/1999] get rid of undocumented(7) symlinks
Bug#39830: debian-policy: [PROPOSED]: get rid of undocu
severity 39830 normal
retitle 39830 [AMENDMENT 28/10/1999] get rid of undocumented(7) symlinks
thanks
I proposed to change the "Manual pages" section of our policy to get
rid of the undocumented(7) symlinks.
This proposal was seconded by Chris Waters <[EMAIL PROTECTED]> and Chris
Lawrence <[EMAIL
Previously Jason Gunthorpe wrote:
> You might want to check out how dpkg actually unpacks the control.tar.gz,
> if memory serves me it uses tar without chroot to do it, which means that
> control.tar.gz could easially contain /bin/sh or something equally nasty..
It uses an internal tar-implementat
Package: debian-policy
Version: 3.0.1.1
Severity: normal
The docs contained in /usr/doc/debian-policy state that docs should go
in /usr/share/doc/.
If any package should comply with policy, it's debian-policy!
Paul Slootman
-- System Information
Debian Release: potato
Kernel Version: Linux pcpa
At 11:42 +0200 1999-10-28, Santiago Vila wrote:
On Wed, 27 Oct 1999, Joel Klecker wrote:
At 14:42 +0200 1999-10-27, Santiago Vila wrote:
> I doubt gcc works without ldso ;-)
Sure it does, it's not a libc5 executable.
Ooops! I forgot that libc6 uses its own dynamic linker.
Why is ldso still e
> Joseph Carter writes:
JC> 1999 at 10:56:45PM -0700, Joey Hess wrote:
>> > * FHS compliant location of examples (closes: #42849)
>>
>> I don't think we have a consensus on this one, though as the
>> proiposer, I'll be happy if no one agrees. :-)
JC> I don't agree with you. => I'd say
Hi,
>>"Paul" == Paul Wade <[EMAIL PROTECTED]> writes:
Paul> Maybe the role of policy is primarily oriented towards
Paul> delivering a stable base system and maybe that doesn't apply
Paul> any more when you start modifying things and building things on
Paul> your own.
Your machine, you
Hi,
>>"Paul" == Paul Wade <[EMAIL PROTECTED]> writes:
Paul> Recently I built the latest X for slink and did so by installing
Paul> kernel-headers (2.2.12) and the "legacy" symlinks for
Paul> /usr/include/(asm,linux). Seems X needed some constants for support of
Paul> newer hardware.
Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Julian Gilbey wrote:
>> Reading bug #31645, it seems clear that the Packaging Manual was
>> accepted as policy, although Joey had reservations.
>>
>> Should I go ahead and make the modifications Manoj proposed?
Joey> I continue to
> > - dpkg-source extracts the Build-* fields from the .dsc and writes
> >them to debian/build-depends.
>
> Sounds a bit too much like magic for me. It should not be necessary to make
> such wiggles to build a package succesfully. By all means make this
> optional. Working from the dsc is fi
> I wonder though, if we are going to do this if it might not make
> sense to rethink the whold sourcepackage-format we have now anyway.
I think both things are independent. If we go for what I proposed, you
still can exchange dpkg-source (the script) to do something more
elaborted than now.
> I
On Thu, 28 Oct 1999, Santiago Vila wrote:
> On Wed, 27 Oct 1999, Joel Klecker wrote:
>
> > At 14:42 +0200 1999-10-27, Santiago Vila wrote:
> > > I doubt gcc works without ldso ;-)
> >
> > Sure it does, it's not a libc5 executable.
>
> Ooops! I forgot that libc6 uses its own dynamic linker.
> Wh
On Wed, 27 Oct 1999, Joel Klecker wrote:
> At 14:42 +0200 1999-10-27, Santiago Vila wrote:
> > I doubt gcc works without ldso ;-)
>
> Sure it does, it's not a libc5 executable.
Ooops! I forgot that libc6 uses its own dynamic linker.
Why is ldso still essential, then?
Maybe it should be just req
On Wed, 27 Oct 1999, Julian Gilbey wrote:
> No. "depend" includes Pre-Depends, [...]
Ooops! You are right.
--
"cdfdd1fe6bf1e8b667d6507e233f92ae" (a truly random sig)
At 14:42 +0200 1999-10-27, Santiago Vila wrote:
On Wed, 27 Oct 1999, Antti-Juhani Kaijanaho wrote:
On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote:
> ldso ?
Do you need this to compile a Hello World?
I doubt gcc works without ldso ;-)
Sure it does, it's not a libc5 executable
On Tue, Oct 26, 1999 at 09:38:35PM +0100, Julian Gilbey wrote:
> > > + However, 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 of
> >
On Tue, Oct 26, 1999 at 10:56:45PM -0700, Joey Hess wrote:
> > * FHS compliant location of examples (closes: #42849)
>
> I don't think we have a consensus on this one, though as the proiposer, I'll
> be happy if no one agrees. :-)
I don't agree with you. => I'd say it's got a nice consensus.
Hi,
On Wed, Oct 27, 1999 at 02:46:45PM +0200, Roman Hodek wrote:
>
> - dpkg-source extracts the Build-* fields from the .dsc and writes
>them to debian/build-depends.
Sounds a bit too much like magic for me. It should not be necessary to make
such wiggles to build a package succesfully. By
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote:
> Firstly, that if we are now demanding build-time dependencies, we are
> asking maintainers to do a *lot* of work. (This took me about 2
> hours, maybe a little bit more.) We ought to think of a better way of
> performing this task i
On Tue, Oct 26, 1999 at 11:02:29PM -0700, Joey Hess wrote:
> Echo -n (#48247)
> * Proposed by Raul Miller.
> * Amend policy to say /bin/sh must be a POSIX shell, but with the
> addition that "echo -n" must not generate a newline.
Ugh, I hadn't realized POSIX doesn't specify echo -n has to
[snip cool stuff]
>
> Known problems, each .deb signed requires you to enter your passphrase
> twice (once for each member), which get's really old after the second or
> third package. Any help with getting around this would be nice. Also note
> that I plan on adding signature checking to dpkg-deb
Sorry for the cross-post, but this is relevant to several groups, and I
wanted to be sure and hit them all.
I have uploaded an experiemental dpkg (1.5.90, which is a pre 1.6.0). It
is mainly testing of unstable features (outlined below). Some of these
features are in regard to some current policy
On Thu, 28 Oct 1999, Wichert Akkerman wrote:
> Let me give another good reason why using a uncompress.sh script is
> something I will never accept: it means that unpacking a package in
> an arbitrary location is no longer a guaranteed safe action, since
> uncompress.sh could do something nasty.
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote:
> Finally, a small point. It may be worth stating that if a package is
> required to satisfy an (install-time) dependency of a listed
> dependency, then it does not need to be listed itself. Although,
> having said this, I think this
Previously sparc porters wrote:
> For this reason, we should not allow arbitrary compression tools to be
> used.
Let me give another good reason why using a uncompress.sh script is
something I will never accept: it means that unpacking a package in
an arbitrary location is no longer a guaranteed s
35 matches
Mail list logo
