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-08-2012, 01:15 PM
Neil Williams
 
Default 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
=============
http://www.linux.codehelp.co.uk/
 
Old 09-08-2012, 02:30 PM
"brian m. carlson"
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sat, Sep 08, 2012 at 10:01:17PM +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?
>
> Imagine a software that builds without a certain -dev package. When present
> this package may be used to activate an additional (optional) feature.

Debian users depend on the package being built in a consistent way. For
example, some packages are built with Kerberos support. While this is
generally optional for most packages, I'd be very upset if, say, the
Debian openssh-server package suddenly lost support for Kerberos because
the maintainer or someone doing an NMU didn't have the appropriate -dev
package installed, since it would mean that package would suddenly fail
to work in a major way for me. Your proposed solution would remove an
important safety check.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 09-08-2012, 02:33 PM
gregor herrmann
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sat, 08 Sep 2012 15:05:21 +0200, Bastian Blank wrote:

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

That's the problem I was alluding to in the paragraph before.

(In the case of docs the build result will probably not be identical
anyway, in the typical case where timestamps or tool versions are
included.)

Please note that I'm not proposing to go that way; I just wanted to
state that I understand the question of the original poster because
I've thought about something similar before.


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: The Eagles: Take It To The Limit
 
Old 09-08-2012, 04:06 PM
Guillem Jover
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

Hi!

On Sat, 2012-09-08 at 17:08:34 +1000, Dmitry Smirnov wrote:
> 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

As other have mentioned I don't think this package is a good idea, but
then some of the cases this tries to address (the “optional” nature of
dependencies for derivatives for example) would get covered by my
build-profiles proposal in #661538, which as stated there might need
proper discussion here, etc.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120908160648.GA12089@gaara.hadrons.org">http://lists.debian.org/20120908160648.GA12089@gaara.hadrons.org
 
Old 09-08-2012, 04:06 PM
Paul Wise
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sat, Sep 8, 2012 at 8:43 PM, gregor herrmann wrote:

> Build-Recommends(-Indep)

I would be interested to see what real use-cases people wanted this
sort of thing for. Dimitry, which specific problem were you trying to
solve when you came up with optional-dev?

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

We have the bootstrap stuff for that:

http://wiki.debian.org/DebianBootstrap

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/CAKTje6GgcYCVNZTcQcaH+ALav1LFHwMMn=qiZxq3W3V1rntTO A@mail.gmail.com
 
Old 09-09-2012, 01:09 AM
Dmitry Smirnov
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sun, 9 Sep 2012 02:06:52 Paul Wise wrote:
> I would be interested to see what real use-cases people wanted this
> sort of thing for. Dimitry, which specific problem were you trying to
> solve when you came up with optional-dev?

Thanks Paul, primarily I was trying to address a problem when package build
unnecessarily fails due to lack of "optional" dependency before an actual
attempt to build.

Due to risk of FTBFS maintainer should be careful with introducing
dependencies that are non-critical for upstream build.
In this case, enabling optional feature by adding dependency may make package
build more fragile and create some difficulties for backporting as
distinguishing required build-dependencies from optional ones may be not
obvious.

Now it became clear that idea is not feasible because it creates more problem
than it solves.

Thanks to feedback from Adam, Neil, Brian, Arno, Guillem, Simon, Geregor,
Bastian and others I can summarise the flaws in the idea:

* buildd servers can't fall back to alternative so even if we can avoid
FTBFS in pbuilder by providing a trivially satisfiable fallback
dependency, that is not the case for our build servers.

* Rarely some packages may be not available for build due to transition,
breakage or other circumstances. With silent fallback instead of FTBFS
package may suddenly and unexpectedly lost some of its functionality.

* NMUs are not guaranteed to be the same as original package due to
possibility of missing optional dependency packages in the environment
where NMU is being prepared.


> > 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.
>
> We have the bootstrap stuff for that:
>
> http://wiki.debian.org/DebianBootstrap

Very interesting, thank you.

Regards,
Dmitry.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209091109.29455.onlyjob@member.fsf.org">http://lists.debian.org/201209091109.29455.onlyjob@member.fsf.org
 
Old 09-09-2012, 01:09 AM
Dmitry Smirnov
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sun, 9 Sep 2012 00:30:41 brian m. carlson wrote:
> Debian users depend on the package being built in a consistent way. For
> example, some packages are built with Kerberos support. While this is
> generally optional for most packages, I'd be very upset if, say, the
> Debian openssh-server package suddenly lost support for Kerberos because
> the maintainer or someone doing an NMU didn't have the appropriate -dev
> package installed, since it would mean that package would suddenly fail
> to work in a major way for me. Your proposed solution would remove an
> important safety check.

Thanks for your brilliant explanation of problem.
You're certainly right but your example is also a case of possible abuse of an
idea because you describe Kerberos as important feature which shouldn't be
optional.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209091109.51782.onlyjob@member.fsf.org">http://lists.debian.org/201209091109.51782.onlyjob@member.fsf.org
 
Old 09-09-2012, 01:14 AM
Russ Allbery
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

Dmitry Smirnov <onlyjob@member.fsf.org> writes:

> Due to risk of FTBFS maintainer should be careful with introducing
> dependencies that are non-critical for upstream build.

I think the opposite is true for the Debian archive. Local package builds
and derivatives may have other needs, but within the Debian archive it's
extremely important that every build of the package will produce the same
results, with the same optional features enabled and the same
configuration. Otherwise, the package can vary in apparently random ways
between different platforms, or between one build and the next.

Therefore, for uploading packages to Debian, one should take the exact
opposite approach: be aggressive about introducing build dependencies to
ensure that the package build is reproducible and consistent, and that any
failure to produce a consistent package results in a FTBFS that preserves
the previous version until a human can look at the problem.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx10vvyk.fsf@windlord.stanford.edu">http://lists.debian.org/87mx10vvyk.fsf@windlord.stanford.edu
 
Old 09-09-2012, 02:04 AM
Paul Wise
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

On Sun, Sep 9, 2012 at 9:09 AM, Dmitry Smirnov wrote:

> Thanks Paul, primarily I was trying to address a problem when package build
> unnecessarily fails due to lack of "optional" dependency before an actual
> attempt to build.

I was more wanting to know which specific problem you were trying to
fix rather than a generality.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6EP8jv7-sB4pk8tjMZubwWHA+icyGSPNo3-jEhqde4_MA@mail.gmail.com">http://lists.debian.org/CAKTje6EP8jv7-sB4pk8tjMZubwWHA+icyGSPNo3-jEhqde4_MA@mail.gmail.com
 
Old 09-10-2012, 12:30 PM
Thorsten Glaser
 
Default Bug#687001: ITP: optional-dev -- fake (empty) dev package

Guillem Jover dixit:

>then some of the cases this tries to address (the “optional” nature of
>dependencies for derivatives for example) would get covered by my
>build-profiles proposal in #661538, which as stated there might need

Yes, please! Besides bootstrapping, use cases do include derived
distributions, such as no SELinux in Univention 2.x (FSVO x which
are not current) which jupp depended on as it can make use of it,
or mksh losing dietlibc-dev in *buntu since move from universe to
main, thus requiring a one-line change for every upload…

bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1209101228240.29940@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1209101228240.29940@herc.mirbsd.org
 

Thread Tools




All times are GMT. The time now is 08:33 PM.

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