Steve Langasek writes:
> On Wed, Jul 29, 2009 at 11:30:33PM +0200, Goswin von Brederlow wrote:
>> >> Moreover, this is not the only exception. Thousands of desktop and server
>> >> packages that contains executable binaries (applications) compiled from
>> >> C/C++/Pascal/etc. also have arch-depen
On Wed, Jul 29, 2009 at 11:30:33PM +0200, Goswin von Brederlow wrote:
> >> Moreover, this is not the only exception. Thousands of desktop and server
> >> packages that contains executable binaries (applications) compiled from
> >> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - pa
Steve Langasek writes:
> On Wed, Jul 29, 2009 at 11:20:20PM +0200, Goswin von Brederlow wrote:
>> You raise an interesting point there with -dbg packages. Esspecially
>> considering the Google SoC project that wants to automatically build
>> -dbg packages for everything in debian. Those .ddeb pac
>> I would still want that multi-arch dependencies would be specified at
>> one straight place, not two.
>
> For most things it will be the depended on package. Your suggestion
> would make it always be in 2 places (co-installability in the library,
> depends in the dependee). I think the proposed
"Eugene V. Lyubimkin" writes:
> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin" writes:
>>
>>> Goswin von Brederlow wrote:
"Eugene V. Lyubimkin" writes:
>> 2) Tagging package relationships instead of packages means extending
>> the syntax of package relationsships, trusting t
On Wed, Jul 29, 2009 at 11:20:20PM +0200, Goswin von Brederlow wrote:
> You raise an interesting point there with -dbg packages. Esspecially
> considering the Google SoC project that wants to automatically build
> -dbg packages for everything in debian. Those .ddeb packages. Too me
> it seems that
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>
>> Goswin von Brederlow wrote:
>>> "Eugene V. Lyubimkin" writes:
> 2) Tagging package relationships instead of packages means extending
> the syntax of package relationsships, trusting the binary packages to
> get the depe
"Eugene V. Lyubimkin" writes:
> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin" writes:
2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right
>>> You'll have to do it so
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>>> 2) Tagging package relationships instead of packages means extending
>>> the syntax of package relationsships, trusting the binary packages to
>>> get the depends right
>> You'll have to do it sooner or later. At least for already men
"Eugene V. Lyubimkin" writes:
> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin" writes:
>>> What the multiarch spec proposes now is package-oriented approach: the
>>> package
>>> should define whether it is 'same' or 'foreign' kind. This is not
>>> straightforward, because in fact not the
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>> What the multiarch spec proposes now is package-oriented approach: the
>> package
>> should define whether it is 'same' or 'foreign' kind. This is not
>> straightforward, because in fact not the package decides it's multiarch
>> 'role
Steve Langasek writes:
> Hi Eugene,
>
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. also have arc
Discussions should probably go to debian-dpkg.
"Eugene V. Lyubimkin" writes:
> Hi Goswin, hi -devel,
>
> I would somewhat object to Multi-Arch field in the long run, and here are my
> thoughts.
>
> What the multiarch spec proposes now is package-oriented approach: the package
> should define whe
Hi Steve,
Steve Langasek wrote:
> Hi Eugene,
>
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. als
Hi Eugene,
On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies -
Hi Goswin, hi -devel,
I would somewhat object to Multi-Arch field in the long run, and here are my
thoughts.
What the multiarch spec proposes now is package-oriented approach: the package
should define whether it is 'same' or 'foreign' kind. This is not
straightforward, because in fact not the pa
16 matches
Mail list logo
