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. Kle
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
bzip
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
[SNIP my (last) wording]
Julian> I'm not sure how this fits in cleanly with the existing
Julian> wording. Can I suggest the following instead:
[SNIPPED Julian's patch for policy]
[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 usin
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,
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 unpac
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 changelo
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 a
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 j
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 second.
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
available
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
> 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 glib
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 everyt
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 m
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
:-) w
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 dependen
On Tue, Oct 26, 1999 at 09:51:05PM -0700, Joey Hess wrote:
> 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
> almo
Remember the definition of build-essential:
+
+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 Wor
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
Joey Hess <[EMAIL PROTECTED]> wrote:
> 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 an
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++
> lib
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] % http:/
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 circumstan
> 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-)essen
> 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 alread
> 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 li
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 broke
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 metapacka
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 time.
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 n
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
> 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
ex
> 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 requi
> 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.
If you really want to (more or less) automate it, it's really not
easy... But for most packages, src-deps are rather clear. It seems
> 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 wordin
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-* fiel
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, ma
> 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
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 incl
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 disagre
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 Wed, 27 Oct 1999, Ben Collins wrote:
> 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.
I basically agree. What we
[I've chosen to Bcc: debian-devel because the debian-devel side of
this thread is getting out of hand.]
On Wed, Oct 27, 1999 at 04:30:07PM +0200, Joost Kooij wrote:
> > If a script requires
> > non-POSIX features from the shell interpreter, the appropriat
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 fullfilled then? What happe
> 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 li
On Wed, Oct 27, 1999 at 12:03:10AM +0200, Goswin Brederlow wrote:
>
> What about rar or mathematical/fractal compressors? For some data far
> better compression can be gained with a specialised packer.
>
> I realy like the support for bzip2 and I´m all for it. I just want to
> mention that maybe
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 definiti
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
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
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
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 com
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 su
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)
---
[EMAI
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 fellow
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
r
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 alre
On Wed, Oct 27, 1999 at 03:46:54PM +0200, Wichert Akkerman wrote:
> 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.
Uhhh... what? Did you misunderstand me?
I
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 vfor
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
> The link on the web page goes to:
>
> ftp://ftp.debian.org/debian/doc/package-developer/menu_policy.txt
> ^ must be "-"
Thanks! Just fixed in my draft version.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
86 matches
Mail list logo
