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
> 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 o
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
Bui
> 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
> 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
tro
> 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 th
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'
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), package7(
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 cr
> 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
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, her
> 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 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
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-, for
> > HURD-based
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
Joel Klecker wrote:
> I just realized I have to object to this proposal
I hope this isn't another case of a formal objection without even talking it
over first?
> on the grounds that
> it doesn't allow me to correctly specify glibc's source depends.
> I need them conditional on DEB_HOST_GNU_SYST
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-, for
HURD-based GNU systems I need hurd-dev
> 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 pa
> 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-*' t
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
>Bu
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 Edw
Antti-Juhani Kaijanaho wrote:
> And I'm still looking for another second.
I second this proposal.
--
Stefan Gybas
I second this proposal.
--
"04a94df3723d0d4e76f1f34d5146c6dc" (a truly random sig)
> 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
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, conside
> - 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 (
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 t
> 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 s
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 gl
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/Confli
> 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 fields, but I think it's going to lead to a lot of
> confusion, particularly for new maintainers. Why not name them
> Src-Depends, Src-Indep-Depen
> IMHO, we will have to name specific packages. However, unlike Roman,
> I hesitate to provide a huge default set. "make" of course sounds
> reasonable, "dpkg-dev" anyway, but "texinfo" not. texinfo *was* in
> the tetex packages, and I had some trouble to compile some packages
> on the Hurd before
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 fields, but I think it's going to lead to a lot
> of confusion, particularly for n
If I understand the proposal, I think I have a strong objection to
the names of the fields.
> 2) Summary
>
> 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
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 me
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 upd
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.
> 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
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
> S
On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:
> +
> +It is not necessary for a source package to specify
> +dependencies on the following packages: packages which are
> +marked Essential; packages with the priority
> +required; the dpk
> > 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 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 n
> The build bot people have a partial solution of their own. Yet, we
> still don't have a general way of specifying these dependencies in
> our packages.
Yep, and I agree that we should have such a thing. The "partial
solution" you mention is a (complete) central database of source
dependencies,
On Wed, 14 Jul 1999, Adam Heath wrote:
> On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:
>
> Look good, except for one thing. How would you handle the case where
> debian/control is generated from debian/control.in?
The usual debian/control file is already some sort of "control.in", since
it
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 Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:
Look good, except for one thing. How would you handle the case where
debian/control is generated from debian/control.in? dpkg-buildpackage would
not be able to check for dependencies in this case, until control is
generated, but you can't call d
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
http://master.debian.org/~ajk/proposal.txt >
1) Introduction
We've been kicking around the idea of build-time dependencies (ak
47 matches
Mail list logo
