FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-10-2012, 12:46 PM
Jon Dowland
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote:
> When building for as many architectures as we have, situation when some
> dependencies are missing (or can't exist) on some architectures is not rare.
>
> However we still want to build our packages with all features possible.

You should have two (or more) binary targets, each of which excludes the
architecture(s) that do not support the particular feature. E.g. if baz is
not available on hurd:

Package: foo
Architecture: any !hurd
Build-Depends: bar libbaz-dev

(I forget the precise syntax for excluding an arch here)
and

Package: foo-hurd
Build-Depends: bar
Architecture: hurd

Or possibly in some circumstances

Package: foo-minimal
Build-Depends: bar
Architecture: any

…where foo without baz might be useful for someone on any architecture.

Explain the differences clearly in the package long description.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120910124617.GF26700@debian
 
Old 09-10-2012, 01:53 PM
Dmitrijs Ledkovs
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On 10 September 2012 13:46, Jon Dowland <jmtd@debian.org> wrote:
> On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote:
>> When building for as many architectures as we have, situation when some
>> dependencies are missing (or can't exist) on some architectures is not rare.
>>
>> However we still want to build our packages with all features possible.
>
> You should have two (or more) binary targets, each of which excludes the
> architecture(s) that do not support the particular feature. E.g. if baz is
> not available on hurd:
>
> Package: foo
> Architecture: any !hurd
> Build-Depends: bar libbaz-dev
>
> (I forget the precise syntax for excluding an arch here)
> and
>
> Package: foo-hurd
> Build-Depends: bar
> Architecture: hurd
>
> Or possibly in some circumstances
>
> Package: foo-minimal
> Build-Depends: bar
> Architecture: any
>
> …where foo without baz might be useful for someone on any architecture.
>

Sure, but is that allowed? Specifying Build-Depends in the Package stanzas?

My understanding was that Build-Depends are specified in the Source:
paragraph. The "-full / -minimal" binary package split, gets rid of
the optional run time depends, but this does not remove the build-time
dependency.

Regards,

Dmitrijs.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANBHLUht1NbWk5vma1-X3WX0uJvCJfaHx9VcODkDp0BfxEzprg@mail.gmail.com">ht tp://lists.debian.org/CANBHLUht1NbWk5vma1-X3WX0uJvCJfaHx9VcODkDp0BfxEzprg@mail.gmail.com
 
Old 09-10-2012, 02:00 PM
Dmitrijs Ledkovs
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On 8 September 2012 09:30, Adam Borowski <kilobyte@angband.pl> wrote:
> On Sat, Sep 08, 2012 at 05:08:34PM +1000, Dmitry Smirnov wrote:
>> Package: wnpp
>> Package name: optional-dev
>>
>> ########
>>
>> There are situations when some of the libraries listed in Build-Depends
>> are optional i.e. build system is smart enough to avoid failure when
>> such library is missing.
>>
>> Often some development libraries are not available on all architectures
>> in which case maintainer should know beforehand which architectures may
>> satisfy this dependency and maintain an up-to-date list of architectures
>> for such packages, like in the following example:
>>
>> Build-Depends: libchamplain-gtk-0.12-dev [!m68k !sh4],
>> libopenipmi-dev [!hurd-any !arm]
> [...]
>> All the above problems may be addressed by using this package as
>> alternative to optional build dependency like in the example below:
>>
>> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
>> libopenipmi-dev | optional-dev
>
> (Using "Build-Depends: libfoo-dev | optional-dev" below.)
>
> I'm afraid this is a bad idea for three reasons:
>
> 1. you'd get a misbuild if libfoo-dev happens to be temporarily
> uninstallable due to a transition of something it depends on,
> it or one of its dependencies happen to wait for a co-installed
> multiarch package, and so on
>
> 2. same, if libfoo-dev is not yet built. It can happen if it has just been
> uploaded, we're in the middle of an archive rebuild (a new arch, some
> derivative), etc.
>
> 3. don't certain build modes (sbuild IIRC) ignore any alternatives in the
> first place? If so, you'll cause a FTBFS.

4. the optional-dev can then be only used once, as once it's installed
to satisfy one OR dependency.... you will not get the "real" once any
more.

I had a valid reason to use such "fake" or dependencies. When a -dev
package splits into two & you want to build across distribution
releases without modifying your packaging.

gtkhtml was split into gtkhtml and gtkhtml-editor, to use single
packaging across distro releases I did a dance of: gtkhtml-editor-dev
| gtk-dev, gtkhtml-dev. And didn't specify gtk explicitely as it was
pulled in by gtkhtml anyway. [1]


[1] package names are for demonstration purposes only from my head, I
am sure their real names are slightly different, but you get the
point.

Regards,
Dmitrijs.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CANBHLUhsieLHD_wz1XKo4_+miNHkk-DT+Eeh5S-tOHiDr7V7SA@mail.gmail.com">http://lists.debian.org/CANBHLUhsieLHD_wz1XKo4_+miNHkk-DT+Eeh5S-tOHiDr7V7SA@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 02:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org