[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

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


Reply to: