Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1209101228240.29...@herc.mirbsd.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120910124617.GF26700@debian
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On 10 September 2012 13:46, Jon Dowland j...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluht1nbwk5vma1-x3wx0ujvcjfahx9vcodkdp0bfxez...@mail.gmail.com
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On 8 September 2012 09:30, Adam Borowski kilob...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhsielhd_wz1xko4_+minhkk-dt+eeh5s-tohidr7v...@mail.gmail.com
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 only...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209081708.34882.only...@member.fsf.org
Re: 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 signature.asc Description: Digital signature
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209081137.34658.hol...@layer-acht.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/504b26b5.4050...@debian.org
Re: 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 signature.asc Description: OpenPGP digital signature
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209082201.18803.only...@member.fsf.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209082213.48035.only...@member.fsf.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209082234.09025.only...@member.fsf.org
Re: 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 signature.asc Description: Digital signature
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On Sat, 8 Sep 2012 22:01:17 +1000 Dmitry Smirnov only...@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/ pgpSIqhQ8J3Ei.pgp Description: PGP signature
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120908130521.ga1...@wavehammer.waldi.eu.org
Re: 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 signature.asc Description: Digital signature
Re: 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 signature.asc Description: Digital signature
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GgcYCVNZTcQcaH+ALav1LFHwMMn=qizxq3w3v1rnt...@mail.gmail.com
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120908160648.ga12...@gaara.hadrons.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209091109.29455.only...@member.fsf.org
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209091109.51782.only...@member.fsf.org
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
Dmitry Smirnov only...@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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx10vvyk@windlord.stanford.edu
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6ep8jv7-sb4pk8tjmzubwwha+icygspno3-jehqde4...@mail.gmail.com
