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

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

On Sat, 8 Sep 2012 22:01:17 +1000
Dmitry Smirnov <onlyjob@member.fsf.org> 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.
> Imagine a software that builds without a certain -dev package. When present 
> this package may be used to activate an additional (optional) feature.

Builds need to be reproducible so that when there needs to be an NMU it
does not rebuild with different options merely because something extra
has been installed. DEB_BUILD_OPTIONS exists for that support.

Conditional builds are a bad idea. Specify the functionality for each
arch and ensure that a later build does not change the functionality.

This is where auto-detection in ./configure is also a bad idea -
packages should ensure that dependencies which are auto detected are
always available where supported via Build-Depends and [$arch], even
using Build-Conflicts if necessary.

> 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.

So specify that using the existing !$arch support.
> However we still want to build our packages with all features possible.

... but not surprise everyone when a simple binNMU for some other
reason results in a change of 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.

Maintenance is not easier if builds at a later date give a completely
different package.

"Optional build-dependencies" are best supported via DEB_BUILD_OPTIONS
so that if the same options are always given, the build always prepares
the same package whatever else is installed on the system in question.

That is the only way to ensure that someone can safely do an NMU on the
package months after the last maintainer upload.


Neil Williams

Attachment: pgpBzv669cYYl.pgp
Description: PGP signature

Reply to: