On Tue, 2008-06-24 at 10:55 +0200, Stefano Zacchiroli wrote:
> Anyhow, we have to choose among:
> 1) document and make the procedure work
> 2) bug the packages which are using the undocumented procedure
Seconded.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tro
Michael Banck <[EMAIL PROTECTED]> writes:
>> Package: type-handling
> Well, that's the good-old type-handling, something we hoped we wouldn't
> need in 2008 anymore.
>
>
> Michael
I thought so too but I can't find any of the type-handling magic for
install time depends in dpkg. Only the buildti
On Mon, Jun 23, 2008 at 07:36:09PM +0200, Raphael Hertzog wrote:
> > It probably should if all of the software or at least most (plus all of
> > the package installation software) supports them properly. Does it?
>
> No. The only support that dpkg has is that those arch-limitations are used
> by
On Mon, 23 Jun 2008, Russ Allbery wrote:
> > I've found no similar text for run-time relationships.
> >
> > Should the policy be updated on this?
>
> It probably should if all of the software or at least most (plus all of
> the package installation software) supports them properly. Does it?
No.
On Sun, Jun 22, 2008 at 09:33:14PM +0200, Goswin von Brederlow wrote:
> On a hunch I checked the Packages.gz files on my system and found the
> following example:
>
> Package: libgnomevfs2-dev
> Architecture: amd64
> Source: gnome-vfs
> Version: 1:2.22.0-4
> Depends: libgnomevfs2-0 (= 1:2.22.0-4),
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> On Mon, Jun 23, 2008 at 11:34:35AM +0200, Goswin von Brederlow wrote:
>> Different situation. The ocaml debs have the same depends on every
>> architecture for the individual deb. They might differ between debs
>> but not between archs for one arch:
Terrific, I will give that a try, thanks very much!
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
> Interesting.
>
> The problem with them is that policy does not allow them :-) Well, to be
> precise, policy mentions that build-time relationships in debian/control
> can be restricted to a certain set of architectures; it does not state
> anything
On Mon, Jun 23, 2008 at 11:34:35AM +0200, Goswin von Brederlow wrote:
> Different situation. The ocaml debs have the same depends on every
> architecture for the individual deb. They might differ between debs
> but not between archs for one arch:all deb.
Nope. I was talking about OCaml programs sh
On Mon, Jun 23, 2008 at 11:26:21AM +0200, Ove Kaaven wrote:
> What is the problem with arch-specific dependencies in control? I've
> used them just fine (in wine, see libwine-dev) for a while, no apparent
> problems. I think they do only work for arch:any packages, though, as
> they seem to b
Ove Kaaven wrote:
> Stefano Zacchiroli skrev:
>> Since apparently there are quite cases like that, what is the reason for
>> forbidding arch-specific dependencies in control? Can we reconsider
>> that?
>
> What is the problem with arch-specific dependencies in control? I've
> used them just fine (
piler is not available.
Different situation. The ocaml debs have the same depends on every
architecture for the individual deb. They might differ between debs
but not between archs for one arch:all deb.
The problem was an arch dependent depends in the binary deb, not
debian/control. So, while I
Stefano Zacchiroli skrev:
Since apparently there are quite cases like that, what is the reason for
forbidding arch-specific dependencies in control? Can we reconsider
that?
What is the problem with arch-specific dependencies in control? I've
used them just fine (in wine, see libwine-dev) for a
On Thu, Jun 19, 2008 at 04:28:28PM -0400, Adam C Powell IV wrote:
> I maintain a set of packages which depend openmpi which is missing on
> certain architectures. To get around the latter problem, I use
I've frequently a similar issues: OCaml programs compiled in bytecode
depends on C stubs to in
Adam C Powell IV <[EMAIL PROTECTED]> writes:
> On Sun, 2008-06-22 at 18:31 +0200, Goswin von Brederlow wrote:
>> Adam C Powell IV <[EMAIL PROTECTED]> writes:
>>
>> > Because hypre upstream doesn't make static libs, and I got tired of
>> > making a new patch with every release, libhypre-dev is arc
On Sun, 2008-06-22 at 18:31 +0200, Goswin von Brederlow wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:
>
> > Because hypre upstream doesn't make static libs, and I got tired of
> > making a new patch with every release, libhypre-dev is arch all without
> > static libs. However, it needs to
Adam C Powell IV <[EMAIL PROTECTED]> writes:
> Because hypre upstream doesn't make static libs, and I got tired of
> making a new patch with every release, libhypre-dev is arch all without
> static libs. However, it needs to depend on openmpi on some arches, and
> lam4-dev on others. Using the s
Greetings,
I maintain a set of packages which depend openmpi which is missing on
certain architectures. To get around the latter problem, I use
arch-dependent Build-Depends to specify openmpi where available and lam
otherwise (though the buildd report for hypre on s390 shows it doesn't
seem to un
18 matches
Mail list logo
