Previously Marcus Brinkmann wrote:
I agree with Ben that dpkg-source should not care about build dependencies
(hey, it only unpacks the source, I only need ar and tar and gzip for this!)
You two seem to overlook that with dpkg-source I mean the packagename
here, not the script dpkg-source. Klee
There's still problems with using pre-depends to make sure bzip2
is installed. It's not exactly what pre-depends was intended for. It's
not going to be pretty if a user tries to remove bzip2 and dselect shoots
up the dependency/conflict screen and marks every single package that was
[I've elected not to Cc: debian-devel]
On Tue, Oct 26, 1999 at 08:32:18PM -0400, Chris Pimlott wrote:
There's still problems with using pre-depends to make sure bzip2
is installed.
If we decide to use bzip2 in this capacity the package should be
required and essential.
--
Raul
On Tue, Oct 26, 1999 at 05:06:34PM -0400, Chris Pimlott wrote:
On 21 Oct 1999, Goswin Brederlow wrote:
Of cause policy should encourage to use bzip2 (or gzip if smaller) and
base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so
that one can update debian. Any package using a
On Tue, Oct 26, 1999 at 11:23:24PM +0200, Goswin Brederlow wrote:
Chris Pimlott [EMAIL PROTECTED] writes:
You would need a switch case statement that tests for all possible
formats that might be allowed.
Having an uncompress.sh the procedure will be identical for all
compressors, just
On Wed, Oct 27, 1999 at 12:14:05AM +0200, Marcus Brinkmann wrote:
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote:
Sbuild calls dpkg-source to unpack, what does it have to do with the
source format?! All it has to do is call whatever executable is needed for
the unpacking. It
A draft version of the policy package which I intend to upload as
3.1.0.0 soon is now available:
http://www.debian.org/~jdg/debian-policy_3.1.0pre1.tar.gz
http://www.debian.org/~jdg/debian-policy_3.1.0pre1_all.deb
http://www.debian.org/~jdg/packaging-manual_3.1.0pre1_all.deb
The
On Tue, Oct 26, 1999 at 08:32:18PM -0400, Chris Pimlott wrote:
There's still problems with using pre-depends to make sure bzip2
is installed. It's not exactly what pre-depends was intended for. It's
not going to be pretty if a user tries to remove bzip2 and dselect shoots
up the
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?
I continue to disagree that this has any business being in policy.
--
see shy jo
Ben Collins wrote:
On Tue, Oct 26, 1999 at 05:32:12PM +0100, Julian Gilbey wrote:
OK, almost there. But one quickie:
The sentence:
A package may not modify a conffile of another package.
was replaced by something better, but I'm not sure what the conclusion
was. How about:
Julian Gilbey wrote:
I'm not quite clear from the bug logs what the final agreed wording is
for this proposal. Please could you let me know?
I don't know that we ever reached a consensus on this proposal. Or rather we
almost did, and then it devolved into many little arguments.
--
see shy jo
Processing commands for [EMAIL PROTECTED]:
retitle 40934 [ACCEPTED 10/26/99] changelog.html.gz sanitization
Bug#40934: PROPOSAL: changelog.html.gz sanitization
Changed Bug title.
forwarded 40934 debian-policy@lists.debian.org
Bug#40934: [ACCEPTED 10/26/99] changelog.html.gz sanitization
Noted
reopen 29522
thanks
No, I can tell you from recent experience that the packaging manual's
example for diversions is wrong.
The postrm example is correct, but the preinst one isn't.
The preinst should be:
if [ install = $1 -o upgrade = $1 ]; then
dpkg-divert --package
At 10:28 -0400 1999-10-26, Raul Miller wrote:
It looks good. It looks like appropriate links are implemented as well.
I put some symlinking code into the libc6 postinst because
/usr/include/paths.h defines _PATH_MAILDIR to /var/mail, and there is
quite a bit of software about that uses that
[ Note: quoting the entire thing since this may have been missed due
to lame original subject ]
At 10:03 -0400 1999-10-03, Raul Miller wrote:
Package: debian-policy
Version: 3.0.1.1
Proposal to change section 2.1.4
Included in this message: diff against 3.0.1.1, and forwarded copy
of
Processing commands for [EMAIL PROTECTED]:
reopen 29522
Bug#29522: [PROPOSED]: clarification needed about diversions
Bug reopened, originator not changed.
thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bugs database)
Julian Gilbey 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 note that the new policy says:
It will not be necessary to explicitly specify build-time relationships
Here's what's been happening on debian-policy this week.
This is another summary of two weeks of activity on the policy list.
Work is underway for a new release of policy.
Note: for details of the policy process, see
http://www.debian.org/~srivasta/policy/ch3.html. Also, this summary is
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
The kernel headers don't change much these days on stable releases, yet
the Debian libc packages continue to carry with them full sets of kernel
I also second this proposal.
Alexander
--
Heute nacht war mir fuenf Minuten langweilig... -- Gabriel Krabbe
Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
I second that proposal. About the escape codes I do not
know what to do (you have to sort it out), but the echo -n
is used too often and Herbert Xu wanted either a policy
change or put it out after potato is released, iirc.
So for such arghful things, I second this proposal.
scnr,
Alexander
--
Wichert Akkerman [EMAIL PROTECTED] writes:
I'm trying to collect a list of everyone who is representing Debian
in some way somewhere. So if you are representing Debian at your
local LUG in some official way, or with an organization like LPI,
LSB, at an expo or somewhere else, please send me
b) supports multiple patches
That's a nice goal, but has nothing to do with source-dependencies...
c) can setup a buildroot and start building everything that is needed to
build a package
Ouch... Do you want to build glibc before building any package? And
build all src-deps of glibc
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote:
Previously Antti-Juhani Kaijanaho wrote:
How do you define complete implementation?
A dpkg-source that:
a) supports build-dependencies
b) supports multiple patches
c) can setup a buildroot and start building everything that
On Tue, Oct 26, 1999 at 10:56:45PM -0700, Joey Hess wrote:
in C or C++. The required packages are called _build-essential_, and an
informational list will be published separately from this document.
I don't see that list.
I've been thinking about publishing this list as a task
On Tue, 26 Oct 1999, Julian Gilbey wrote:
How about:
Packages may not depend on packages with lower priority values
(excluding build-time dependencies). If this should happen, one of
the priority values will have to be adapted.
Maybe the fully correct wording would be:
I still think sbuild is the way to go.
I still think sbuild is not the way to go and would rather see sbuild
modified to handle the new source format.
sbuild will automatically use a new source format as soon as
dpkg-source knows it :-) Actually, sbuild is just a (rather blown-up
:-)
At 11:34 +0200 1999-10-27, Roman Hodek wrote:
c) can setup a buildroot and start building everything that is needed to
build a package
Ouch... Do you want to build glibc before building any package? And
build all src-deps of glibc transitively (this includes gcc, bzip2,
tetex-bin,
On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote:
[...]
I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred
to me as a dependency, but I guess it is. What else? patch? We need
to discuss what's build-essential anyway. Here's a start:
libc-dev
gcc
g++
(Sorry, bad manners to followup own email, but more came to me..)
On Wed, Oct 27, 1999 at 03:50:06AM -0700, Seth R Arnold wrote:
On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote:
[...]
I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred
to me as a dependency,
Remember the definition of build-essential:
+ p
+It will not be necessary to explicitly specify build-time
+relationships on a minimal set of packages that are always
+needed to compile, link and put in a Debian package a
+standard Hello
On Wed, Oct 27, 1999 at 12:16:17PM +0200, Roman Hodek wrote:
My personal view of sbuild is that it's a tool for mass builds. If
Debian wants to adopt it as replacement for dpkg-buildpackage, please
go ahead, I won't mind :-) But it was written with a different
intention.
How about we just
On Wed, Oct 27, 1999 at 03:41:00AM -0700, Joel Klecker wrote:
I've eliminated the tetex-bin dependency, BTW. bzip2 hadn't occurred
to me as a dependency, but I guess it is. What else? patch? We need
to discuss what's build-essential anyway. Here's a start:
libc-dev
gcc
g++
On Wed, Oct 27, 1999 at 07:22:00AM -0400, Ben Collins wrote:
Should dpkg-dev possibly depend on anything we consider to be assumed
for build dependencies?
I'd create a separate metapackage for that, as I already proposed elsewhere.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] %
On Tue, Oct 26, 1999 at 10:16:05PM -0700, Joel Klecker wrote:
It's also been suggested that --rename is potentially harmful.
--rename would be harmful if the divert target would be the /bin/sh
symlink. [Or some other target which is critical to system integrity.]
In almost all other
He means have that as an ability, but I don't see that as relevant
to what we *need* for source depends to be useful.
Yep :-)
As an aside, I don't think the present dpkg-buildpackage is a
suitable platform for dependency checking, being that it's only a
shell script.
This was my idea,
autoconf ?
bin86 ?
ldso ?
All to specific, specially bin86 :-) (it's i386-only...)
supporting stuff
tar ?
cpio ?
gzip ?
bzip2 ?
find ?
perl ?
tar and gzip are already needed by dpkg and dpkg-source. BTW (contrary
to my previous post) I'd say we should omit (binary-)essential
BTW, what do you people think of the metapackage idea (see the new Policy
draft thread)?
Such a metapackage surely will be useful. However, I think the
build-essential list still should be written down somewhere :-)
Roman
On Wed, Oct 27, 1999 at 02:46:42PM +0300, Antti-Juhani Kaijanaho wrote:
On Wed, Oct 27, 1999 at 07:22:00AM -0400, Ben Collins wrote:
Should dpkg-dev possibly depend on anything we consider to be assumed
for build dependencies?
I'd create a separate metapackage for that, as I already
How about we just borrow a little code for dpkg-buildpackage from
sbuild then? :)
My idea :-) Please wait for the upcoming post... :-)
Roman
On Wed, Oct 27, 1999 at 08:00:47AM -0400, Ben Collins wrote:
I'd create a separate metapackage for that, as I already proposed elsewhere.
But then dpkg-dev should still depend on that (which would be good and let
it get rid of all the other deps it needs/has).
On the contrary: dpkg-dev
On Wed, Oct 27, 1999 at 01:56:04PM +0200, Roman Hodek wrote:
Such a metapackage surely will be useful. However, I think the
build-essential list still should be written down somewhere :-)
Well, if the metapackage is in the available file, the following
shell code will create such written list
This is trivially automatisable.
Ok :-) I simply think it's nicer to have a file under
docs/package-developer (besides policy) that clearly says what is
build-essential. It doesn't matter if that is built automatically or
not.
Roman
On Wed, 27 Oct 1999, Antti-Juhani Kaijanaho wrote:
On Tue, Oct 26, 1999 at 10:56:45PM -0700, Joey Hess wrote:
in C or C++. The required packages are called _build-essential_, and an
informational list will be published separately from this document.
I don't see that list.
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 ;-)
[ Every required-and-essential package should be included in the list,
because a broken
Here are some thoughts how source dependencies can be reasonbly
implemented for now, and kind of a vision for the future:
- dpkg-source extracts the Build-* fields from the .dsc and writes
them to debian/build-depends.
This is necessary, as the actual checking is done before building,
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
Well, if the metapackage is in the available file, the following
shell code will create such written list (untested):
...
Last time I checked, apt-get update did not update the available file.
--
Raul
On Wed, Oct 27, 1999 at 09:06:00AM -0400, Raul Miller wrote:
Last time I checked, apt-get update did not update the available file.
That's true but irrelevant. I was providing an existence proof, not
a fully thought-out implementation. I will probably just generate the
information at
At 13:51 +0200 1999-10-27, Roman Hodek wrote:
I've eliminated the tetex-bin dependency, BTW.
Ah, no more readlink calls? Fine, deleting it...
Actually no, I've simply put readlink.c into debian/scripts and I
compile it at build time.
Other dependencies I have registered: gettext and
OK, I've just tried to calculate the build-time dependencies for
debian-policy, and here are some thoughts.
It's not easy. In fact it's *really* not easy.
I first tried running strace on the build process, but due to the
presence of a vfork, I missed most of the interesting stuff.
So strace is
Hi,
On Tue, 26 Oct 1999, Eric Weigel wrote:
From Debian Policy Manual, version 3.0.1.1, 1999-08-16:
4.4 Scripts
...
The standard shell interpreter `/bin/sh' may be a symbolic link to any
POSIX compatible shell. Thus, shell scripts specifying `/bin/sh' as
interpreter may only use
Julian Gilbey wrote:
* FHS compliant location of examples (closes: #42849)
To quote the latest message in the bug report, from Joey:
Ok, to sum up, I have 2 seconds, and the only concern anyone's had is if
these files will ever appear at all. I have found one occurrance of binary
I note that the new policy says:
It will not be necessary to explicitly specify build-time relationships
on a minimal set of packages that are always needed to compile, link
and put in a Debian package a standard Hello World! program written
in C or C++. The required
On Tue, 26 Oct 1999, Julian Gilbey wrote:
How about:
Packages may not depend on packages with lower priority values
(excluding build-time dependencies). If this should happen, one of
the priority values will have to be adapted.
Maybe the fully correct wording would be:
On Wed, Oct 27, 1999 at 02:46:45PM +0200, Roman Hodek wrote:
(I = install, U = upgrade, D = downgrade, R = remove, C = comment)
I like this, makes it easily parsible by other programs.
The problem with this: Currently the .dsc is built before
compiling, and thus the Build-* fields
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote:
OK, I've just tried to calculate the build-time dependencies for
debian-policy, and here are some thoughts.
It's not easy. In fact it's *really* not easy.
When I came up with a simple implementation awhile back, the fakeroot
On Wed, Oct 27, 1999 at 03:17:52PM +0100, Julian Gilbey wrote:
It's not easy. In fact it's *really* not easy.
It is easy. I've specified build-time dependencies on some of my packages
for months now. You just happened to try a nasty case as your first.
Standard packages: dpkg-dev, lynx,
I like this, makes it easily parsible by other programs.
That was the intention :-)
I heard other arguments for and against this. Sometimes I like to
have my build lay around so that I have _exact_ copies of what I
just built, and can go in and see if anything went wrong (make sure
all the
Recently I built the latest X for slink and did so by installing
kernel-headers (2.2.12) and the legacy symlinks for
/usr/include/(asm,linux). Seems X needed some constants for support of
newer hardware. I could have installed kernel-source and I could have even
changed the X source default
On Wed, Oct 27, 1999 at 11:10:33AM -0400, [EMAIL PROTECTED] wrote:
Does adhering to a policy diminish the usefulness of the system? This
should always be seriously considered.
Not when policy is aiding in stability.
Ben
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?
On Tue, Oct 26, 1999 at 09:42:54PM -0700, Joey Hess wrote:
I continue to disagree that
On Tue, Oct 26, 1999 at 10:01:58PM -0700, Joel Klecker wrote:
[ Note: quoting the entire thing since this may have been missed due
to lame original subject ]
Sorry about that.
Thanks,
--
Raul
On Tue, Oct 26, 1999 at 10:56:45PM -0700, Joey Hess wrote:
in C or C++. The required packages are called _build-essential_, and an
informational list will be published separately from this document.
I don't see that list.
I've been thinking about publishing this list as a
Here's notes on the list of accepted amendments vis-a-vis my draft new
version of policy:
Accepted Amendments
MIME support sub-policy (#46516)
Included.
Tech-ctte: /usr/share/doc (#45561)
Included.
Amend contrib definition
What's the actual wording which should go into policy?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
It seems you have not read the amendment. There was a mechanism for
this even in the first draft.
And I would have appreciated these comments at the proposal stage, when
we were still hammering out the thing. I even called for people with
complicated packages to give their input when I
Ben Collins [EMAIL PROTECTED] writes:
On Tue, Oct 26, 1999 at 11:23:24PM +0200, Goswin Brederlow wrote:
Chris Pimlott [EMAIL PROTECTED] writes:
You would need a switch case statement that tests for all possible
formats that might be allowed.
Having an uncompress.sh the procedure
On Wed, Oct 27, 1999 at 06:23:44PM +0200, Goswin Brederlow wrote:
Without that you have to unpack the .deb file, look around for a
data.tar.xxx and make a switch/case over xxx. Each compressor would
need its own entry there and as soon as the third compressor comes up
for debian packages a
Ben Collins writes:
With the current implementation I have, it is a simple matter of adding a
line for each (de)compressor wanted. I think we should choose carefully
what compressions we allow, as it could lead to problems if we don't. For
this reason, we should not allow arbitrary
Goswin Brederlow wrote:
Joey Hess [EMAIL PROTECTED] writes:
Goswin Brederlow wrote:
Whats complicated about using uncompress.sh instead of gzip and
fallback to gzip if not present?
Tons of things. What about programs called in uncompress.sh -- are
dependancies supposed to be
The link on the web page goes to:
ftp://ftp.debian.org/debian/doc/package-developer/menu_policy.txt
^ must be -
HTH,
Jens
P.S.: Please vote against Spam! At
http://www.politik-digital.de/spam/
(Sorry Europeans only)
---
[EMAIL
While this is debated I will upgrade hard drives. The 6 gb is not enough
to continue mirroring debian and debian-non-US anymore. I am only
mirroring i386 and have to usually have to make a delete pass before I can
get all the updates. I can come up with a larger drive but I am thinking
about
Previously Roman Hodek wrote:
Here are some thoughts how source dependencies can be reasonbly
implemented for now, and kind of a vision for the future:
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 would
Previously Antti-Juhani Kaijanaho wrote:
BTW, what do you people think of the metapackage idea (see the new Policy
draft thread)?
It's bad and shouldn't be handled by dpkg. There is an excellent
strategy for implementing this in frontends, see the Apt UI design for
example. In fact libapt
Julian Gilbey [EMAIL PROTECTED] writes:
OK, I've just tried to calculate the build-time dependencies for
debian-policy, and here are some thoughts.
It's not easy. In fact it's *really* not easy.
I first tried running strace on the build process, but due to the
presence of a vfork, I
On Wed, 27 Oct 1999, Raul Miller wrote:
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
Well, if the metapackage is in the available file, the following
shell code will create such written list (untested):
Last time I checked, apt-get update did not update the
76 matches
Mail list logo
