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
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
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.
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
[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
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
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
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 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.
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
> >
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 Wed, 27 Oct 1999, Julian Gilbey wrote:
> No. "depend" includes Pre-Depends, [...]
Ooops! You are right.
--
"cdfdd1fe6bf1e8b667d6507e233f92ae" (a truly random sig)
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 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
> 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
> > - 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
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
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,
>>"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
> 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
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
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
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
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
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
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
> 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, 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
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
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
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?
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.
^^^
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
-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
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
35 matches
Mail list logo
