Roman Hodek wrote:
Hmm... but the parser still has to decide if the thing in parens is an
arch spec or a version spec, which isn't really trivial, as the
version number can be an arbitrary string.
Yes, but a version specification starts with , = or so it can
be decided at the first character
I´d prefer a syntax in the style of /etc/exports, e.g.
Build-Depends: package1, package2(CPU1), package3(!CPU1),
package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
package7(CPU1, = 2.0), package7(!CPU1, = 2.1)
It looks a bit easier to read (and create) to me than the prefix
Are the -Conflicts headers really necessary? So far I have not been
able to think of a use for them, and they complicate the task of the
build daemons (install everything needed to build this package)
unnecessarily.
That's not really true. The parsing is nearly the same, and it's no
trouble
Can we use a format that is more inline with the rest of the depends
stuff? Perhaps:
pkg (= 2.1 i386)
With the 'i386' being whatever specification you want to dream up.
(optional of course)
At least better to parse than package7(CPU1, = 2.0), as the version
can't contain
Roman Hodek wrote:
But it's something different here... It's really trivial to
temporatily uninstall a package and reinstall it later.
What if you can only uninstall the package by deconfiguring another one
that you need? Take this situation:
foo-source has
Build-Depends: gnu1 | gnu2
What if you can only uninstall the package by deconfiguring another one
that you need? Take this situation:
foo-source has
Build-Depends: gnu1 | gnu2
Build-Conflicts: bar
gnu1 has
Depends: bar
Currently bar and gnu1 are installed. Will your five lines of code be
This shouldn't be too hard. You only need a syntax for it. There are several
possibilities:
Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev,
linux-all:kernel-headers-2.0.36
The prefix idea is good, here a suggestion for concrete syntax:
ARCH:packagerestricted to ARCH
On Mon, Aug 02, 1999 at 11:36:19AM +0200, Roman Hodek wrote:
This shouldn't be too hard. You only need a syntax for it. There are several
possibilities:
Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev,
linux-all:kernel-headers-2.0.36
The prefix idea is good, here a
Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your
friend.
If it makes you lucky, think the vars re-named :-) But it really makes
no difference, I meant exactly the same as you, i.e. ARCH == cpu.
Looks good to me. I don't know how many logical operators we should
support, but it
Are the -Conflicts headers really necessary? So far I have not been
able to think of a use for them, and they complicate the task of the
build daemons (install everything needed to build this package)
unnecessarily. We've already seen with binary dependencies that
the Conflicts relationships
Roman Hodek wrote:
The prefix idea is good, here a suggestion for concrete syntax:
I´d prefer a syntax in the style of /etc/exports, e.g.
Build-Depends: package1, package2(CPU1), package3(!CPU1),
package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
package7(CPU1, = 2.0),
On Mon, 2 Aug 1999, Roman Hodek wrote:
Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your
friend.
If it makes you lucky, think the vars re-named :-) But it really makes
no difference, I meant exactly the same as you, i.e. ARCH == cpu.
Looks good to me. I don't know how
I just realized I have to object to this proposal on the grounds that
it doesn't allow me to correctly specify glibc's source depends.
I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based
GNU systems I need to depend on kernel-headers-version, for
HURD-based GNU systems I need
On Mon, Jul 26, 1999 at 10:54:38AM +0200, Roman Hodek wrote:
I see your point, and I can live with the Arch- variants if a majority
wants them.
The majority? There have been, what, probably less than ten people
involved in this discussion. I don't think a majority vote among them
would be of
On Sat, Jul 31, 1999 at 10:24:47PM -0700, Joey Hess wrote:
on the grounds that
it doesn't allow me to correctly specify glibc's source depends.
I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based
GNU systems I need to depend on kernel-headers-version, for
HURD-based
On Sun, Aug 01, 1999 at 06:29:29PM +0200, Marcus Brinkmann wrote:
Whatever you do, please make sure that this proposal is flexible enough to
catch individual Debian architectures, not only Hurd vs. Linux.
Please help in this. You know the problems better than I - what problems
there are that
I strongly agree with the proposal.
Nice to have you on the boat, too :-)
I disagree with Roman's suggestion that we should remove the Arch-
versions because they'd not be used often. I think it important that
the resulting scheme be orthogonal. It should also parallel the
`binary-*'
I would like to use this suggestion. Comments?
See my previous mail: I'd say the -Arch variants are unnecessary, but
if everybody wants them for clearness of design, I won't oppose.
Sounds good. Actually, that was what I had originally in mind. If
there are no objections, I'll make this part
Antti-Juhani Kaijanaho writes (Bug#41232: debian-policy: [PROPOSAL] Build-time
dependencies on binary packages):
I have re-read the discussion, and I think some points raised are valid.
I'm hereby changing my proposal.
The proposal has been seconded by Edward Betts [EMAIL PROTECTED].
I need
On Sun, Jul 25, 1999 at 05:01:48PM +0100, Ian Jackson wrote:
I strongly agree with the proposal. If you still need seconds, count
me as one.
No, I don't, but thanks anyway :-)
I therefore suggest the following list
Build-Depends
Build-Depends-Indep
Build-Depends-Arch
I have re-read the discussion, and I think some points raised are valid.
I'm hereby changing my proposal.
The proposal has been seconded by Edward Betts [EMAIL PROTECTED].
I need his support for these changes, or a second from someone else.
And I'm still looking for another second.
Summary of
- The fields change as follows:
Depends - Build-Depends
Arch-Depends(removed as suggested by Roman Hodek)
Indep-Depends - Build-Indep-Depends
Conflicts - Build-Conflicts
Arch-Conflicts (removed
On Fri, Jul 23, 1999 at 06:23:09PM +0200, Roman Hodek wrote:
Isn't that wrong? I think Build-Indep-{Depends,Conflicts} apply only
to 'binary-indep' (and transitive to 'binary'), but not to 'build'.
Otherwise, you'd have to install Build-Indep-Depends also for the pure
build...
Yes, consider
Yes, consider that a typo. I will not submit another patch as the
fix is obvious.
Yep, that's what I thought as I seconded the proposal :-)
Roman
I second this proposal.
--
04a94df3723d0d4e76f1f34d5146c6dc (a truly random sig)
Well, if the first stanza is global, how about being able to put the
fields in the other stanzas too, to control dependancies on a
per-binary-package basis? You would need to name them prefix,
though.
This seems possible, but I can't see the real advantage of it. You
really seldom build
On 15-Jul-99, 02:51 (CDT), Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote:
On Wed, Jul 14, 1999 at 09:32:22PM -0500, Steve Greenland wrote:
I realize that these would be in the first stanza of the control
file, and therefore don't technically conflict with the binary
Depends/Conflicts
Steve Greenland wrote:
Hmmm. I tend to think of the first stanza in debian/control as the
global stanza, and the rest as per package. Therefore, the use
of Section/Priority is entirely consistent -- default in the first
stanza, overrides where necessary. Thus, having Depends in the global
On Wed, Jul 14, 1999 at 05:15:27PM +0300, Antti-Juhani Kaijanaho wrote:
On Wed, Jul 14, 1999 at 03:20:34PM +0200, Roman Hodek wrote:
Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
should be very rare that someone only builds the arch-indep packages.
So we could merge
On Wed, Jul 14, 1999 at 01:44:46AM -0500, Adam Heath wrote:
Look good, except for one thing. How would you handle the case where
debian/control is generated from debian/control.in?
A source package is required to have a valid debian/control after unpack.
Although the Packaging Manual does not
On Wed, Jul 14, 1999 at 03:20:34PM +0200, Roman Hodek wrote:
Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
should be very rare that someone only builds the arch-indep packages.
So we could merge Arch-Depends into Depends. If one compiles with
dpkg-buildpackage -B, he
For my current system I have defined the following packages as
build-essential:
I wanted to avoid naming specific packages in Policy (I only named two in
the proposal, make and dpkg-dev), since packages change and it would be a
pain in the rear to change policy every time GNU Libc
On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:
+ p
+It is not necessary for a source package to specify
+dependencies on the following packages: packages which are
+marked ttEssential/tt; packages with the priority
+ttrequired/tt;
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote:
My proposal is, in short, the following: Define six new fields for
debian/control and specify their meaning. The six new fields are used
only in .dsc files and in the first paragraph of debian/control. They
are:
* Depends
Small comment: I like the informal way the build-essential
packages are described. However, for practical reasons, it would
help to specify also which ones they are at a given time. For
example:
[...] and packages which are required for compiling and linking a
minimal Hello World program
On Wed, Jul 14, 1999 at 05:59:26PM +0200, Santiago Vila wrote:
The idea would be to provide a real list, but also the rationale from
which the list is derived, so that whenever the list of build-essential
packages change, we just update policy accordingly, without changing the
spirit of it.
On Wed, 14 Jul 1999, Antti-Juhani Kaijanaho wrote:
On Wed, Jul 14, 1999 at 05:59:26PM +0200, Santiago Vila wrote:
The idea would be to provide a real list, but also the rationale from
which the list is derived, so that whenever the list of build-essential
packages change, we just update
Package: debian-policy
Version: 3.0.0.0
Severity: wishlist
This is a long mail. Bear with me, and read at least the summary (section
2). This mail is also available at
URL: http://master.debian.org/~ajk/proposal.txt
1) Introduction
We've been kicking around the idea of build-time
38 matches
Mail list logo
