Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: optional-dev
Version: 20120908
Author: Dmitry Smirnov <onlyjob@member.fsf.org>
License: GPL-3+
Description: fake (empty) dev package
Purpose of this package is to provide an alternative for optional build
dependencies which may not be available on some architectures.

########

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]

From time to time such lists should be re-checked in case library become
available on another architecture or when new architecture is added or
if package is removed from some architectures.

Another challenge is backporting package if some of its optional build
dependencies may not be available on target distribution. For instance
"libchamplain-gtk-0.12-dev" is not available for Squeeze so backporting
would require removing it from Build-Depends.

Finally maintainer might want to mark optional dependencies as such (can
be done with comments).

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209081708.34882.onlyjob@member.fsf.org">http://lists.debian.org/201209081708.34882.onlyjob@member.fsf.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

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.


--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

Hi,

"optional depends" - what?? Thats self contradictory. If a depends it's really
optional, it's not a depends, thus that package is buggy and should not be
fixed by introducing a nonsense package, but by removing this depends.


cheers,
Holger


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209081137.34658.holger@layer-acht.org">http://lists.debian.org/201209081137.34658.holger@layer-acht.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On 08/09/12 08:08, Dmitry Smirnov wrote:
> 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]
[for which a proposed replacement is]
> Build-Depends: libchamplain-gtk-0.12-dev | optional-dev,
> libopenipmi-dev | optional-dev

This doesn't really give enough guarantees (even if sbuild followed
non-first branches in alternative-lists, which IIRC it doesn't). If
champlain happens to be temporarily uninstallable on (say) powerpc at
the time the empathy build happens, we don't want that to mean it
randomly loses features on powerpc, then gains those features back later.

It would perhaps make more sense if there was a way for the libchamplain
maintainer to nominate excluded architectures, so empathy could say
something like:

Build-Depends: libchamplain-...-dev |
champlain-unavailable-on-this-arch

where champlain-unavailable-on-this-arch is arch:any, empty, and built
on exactly those architectures that deliberately don't build champlain.

(I don't think my example works either, again because sbuild only uses
the first alternative, but it seems closer to being right...)

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 504B26B5.4050008@debian.org">http://lists.debian.org/504B26B5.4050008@debian.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

Hi,

On 08.09.2012 13:06, Simon McVittie wrote:
> It would perhaps make more sense if there was a way for the libchamplain
> maintainer to nominate excluded architectures, so empathy could say
> something like:
>
> Build-Depends: libchamplain-...-dev |
> champlain-unavailable-on-this-arch
>

As Adam previously said: buildds do not resolve alternatives. They use
the first dependency or fail to build from source if it isn't available.
Dmitry's proposal has the same problem. Thus, any "Build-Depends: A | B"
does not work for buildds if A is not installable.

The rationale is, that builds should unconditionally result in the same
binary package (I guess).


--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> "optional depends" - what?? Thats self contradictory. If a depends it's
> really optional, it's not a depends, thus that package is buggy and should
> not be fixed by introducing a nonsense package, but by removing this
> depends.

Not at all, it may appears "self contradictory" only because debian/control
"language" doesn't have a right term for it. Or perhaps my wording is not
perfect. If you got the idea, can you suggest a better word?

Imagine a software that builds without a certain -dev package. When present
this package may be used to activate an additional (optional) feature.

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.

So here are two ideas -- one is to clearly see which build-dependencies are
optional i.e. which packages are not critical for successful build;
and another is to nicely and easily handle unsatisfiable non-critical
"dependencies".

The latter will make maintenance easier and may also be helpful for
backporting or even for distributions who borrow our packages but may not have
all their build-dependencies.

Regards,
Dmitry.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209082201.18803.onlyjob@member.fsf.org">http://lists.debian.org/201209082201.18803.onlyjob@member.fsf.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On Sat, 8 Sep 2012 18:30:30 Adam Borowski wrote:
> 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.

Good points, thanks. I did't think of this. Perhaps this idea is not flawless
but we might have a potential for improvement.


> 3. don't certain build modes (sbuild IIRC) ignore any alternatives in the
> first place? If so, you'll cause a FTBFS.

You might know better if that's the case. But if build servers are ignoring
alternatives, that's a (different) problem, right?

I recognise a potential for misuse of trivially satisfiable dependency but
generally speaking you don't blame tool for those who misuse it...

Thanks for sharing your concerns.

Regards,
Dmitry.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209082213.48035.onlyjob@member.fsf.org">http://lists.debian.org/201209082213.48035.onlyjob@member.fsf.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On Sat, 8 Sep 2012 21:06:29 Simon McVittie wrote:
> This doesn't really give enough guarantees (even if sbuild followed
> non-first branches in alternative-lists, which IIRC it doesn't). If
> champlain happens to be temporarily uninstallable on (say) powerpc at
> the time the empathy build happens, we don't want that to mean it
> randomly loses features on powerpc, then gains those features back later.

Right you're concerned that we may not always have all "optional" dependencies
ready for build.

I'm not quite sure this would be the case for generic unversioned
dependencies. The assumption that "optional" packages are generally available
from repository. If so sbuild may not build with the very latest version
available but this is no different from current situation.

If we have an ongoing transition and some packages are temporary broken in
"unstable" then indeed there might be a problem.

Well, now I see it is a bit more complicated than I thought.


> It would perhaps make more sense if there was a way for the libchamplain
> maintainer to nominate excluded architectures, so empathy could say
> something like:
>
> Build-Depends: libchamplain-...-dev |
> champlain-unavailable-on-this-arch
>
> where champlain-unavailable-on-this-arch is arch:any, empty, and built
> on exactly those architectures that deliberately don't build champlain.
>
> (I don't think my example works either, again because sbuild only uses
> the first alternative, but it seems closer to being right...)
>

If only we could express that we want to build with libfoo-dev if it is
available but avoid to demand it... :)

Regards,
Dmitry.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209082234.09025.onlyjob@member.fsf.org">http://lists.debian.org/201209082234.09025.onlyjob@member.fsf.org

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On Sat, 08 Sep 2012 22:01:17 +1000, Dmitry Smirnov wrote:

> On Sat, 8 Sep 2012 19:37:33 Holger Levsen wrote:
> > "optional depends" - what?? Thats self contradictory. If a depends it's
> > really optional, it's not a depends, thus that package is buggy and should
> > not be fixed by introducing a nonsense package, but by removing this
> > depends.
> Not at all, it may appears "self contradictory" only because debian/control
> "language" doesn't have a right term for it. Or perhaps my wording is not
> perfect. If you got the idea, can you suggest a better word?

Build-Recommends(-Indep)

Yes, this is a slippery slope and a can of worms (and probably some
other idioms).

But I see the use case, e.g. for packages that rebuild the
documentation if some tool is available and just skip it gracefully
and use the shipped version, if not.


Cheers,
gregor

--
.'`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Alanis Morisette: Head Over Feet

Bug#687001: ITP: optional-dev -- fake (empty) dev package
 

On Sat, Sep 08, 2012 at 02:43:47PM +0200, gregor herrmann wrote:
> But I see the use case, e.g. for packages that rebuild the
> documentation if some tool is available and just skip it gracefully
> and use the shipped version, if not.

How do you make sure that the uploaded packages are reproducible?

Bastian

--
It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908130521.GA1049@wavehammer.waldi.eu.org">htt p://lists.debian.org/20120908130521.GA1049@wavehammer.waldi.eu.org