Re: dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

On 03/26/2017 09:37 AM, Florian Weimer wrote: > * Guillem Jover: > >>> dlopen()ing dependencies in the way that is most commonly implemented, >>> with dlopen("libimobiledevice.so.6") and dlsym(handle, "idevice_new") >>> or similar, has some practical problems for Debian: >>> >>> * The libraries

Re: dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

On Sun, Mar 26, 2017 at 05:44:20AM +0200, Guillem Jover wrote: > As I've also noted in the past [B], I'd go even further and say that > we need at least to very strongly discourage, but ideally outright ban > the dlopen()ing of shared libraries that are not part of the same > source package or at

Re: Depends/Recommends from libraries

Hi! On Thu, 2017-03-23 at 17:34:58 +, Ian Jackson wrote: > Russ Allbery writes ("Re: Depends/Recommends from libraries"): > > It still feels like needless complexity to me, > > Here is an example I just found. It does not turn out to be a very good examp

Re: dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

* Guillem Jover: >> dlopen()ing dependencies in the way that is most commonly implemented, >> with dlopen("libimobiledevice.so.6") and dlsym(handle, "idevice_new") >> or similar, has some practical problems for Debian: >> >> * The libraries used aren't visible to dpkg-shlibdeps. The maintainer

Re: Depends/Recommends from libraries

On Tue, 2017-03-21 at 12:36:16 +, Ian Jackson wrote: > Russ Allbery writes ("Re: Depends/Recommends from libraries"): > > I think this would be a great way of introducing spurious bugs in our > > distribution from [developers] who don't happen to read the README >

dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

Hi! On Fri, 2017-03-10 at 10:16:58 +, Simon McVittie wrote: > I do not agree that dlopen()ing dependencies (what you have called "dynamic > loading") is something we should encourage over normal linking with -lfoo > (resulting in a DT_NEEDED entry, what you have called "static loading").

Re: Depends/Recommends from libraries

Russ Allbery writes ("Re: Depends/Recommends from libraries"): > It still feels like needless complexity to me, Here is an example I just found. Try, in a fresh stretch chroot apt-get --no-install-recommends install libgtkspell-dev Which you might reasonably do because you

Re: Rethinking dynamic linking a bit (was: Re: Depends/Recommends from libraries)

On Wed, Mar 22, 2017 at 6:17 PM, Christian Seiler wrote: > For $DAYJOB I had to work on Mac OS X a bit, and they have an interesting > feature there: weakly binding to a shared library. Apparently Solaris has support for optional shared libraries:

Rethinking dynamic linking a bit (was: Re: Depends/Recommends from libraries)

On 03/08/2017 11:33 PM, Adam Borowski wrote: > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as C), SHOULD > # NOT declare a

Re: Depends/Recommends from libraries

Russ Allbery writes ("Re: Depends/Recommends from libraries"): > I think this would be a great way of introducing spurious bugs in our > distribution from [developers] who don't happen to read the README > file and miss dependencies they actually need because they're used &

Re: AppStream Re: Depends/Recommends from libraries

On Fri, Mar 10, 2017 at 3:05 AM, Rebecca N. Palmer wrote: > Upstream have since granted permission for the metadata to be MIT, but too > late for the freeze. I'm not on the Release Team, but I think a one-line change to fix the appstream metadata should be easy to

Re: Depends/Recommends from libraries

Wouter Verhelst writes: > On Thu, Mar 09, 2017 at 10:19:10AM -0800, Russ Allbery wrote: >> Now, if this were taken a further step so that dpkg-shlibdeps would >> provide some mechanism to *automatically* add those downstream >> dependencies to packages that depend on the

Re: Depends/Recommends from libraries

* Simon McVittie [170310 05:17]: > On Thu, 09 Mar 2017 at 17:52:05 -0500, Marvin Renich wrote: > > If more upstreams were careful to use dynamic loading in these > > situations, it would be less of a problem. In a perfect world, the > > solution would be for foo's maintainer to

Re: Depends/Recommends from libraries

On Thu, Mar 09, 2017 at 10:19:10AM -0800, Russ Allbery wrote: > Now, if this were taken a further step so that dpkg-shlibdeps would > provide some mechanism to *automatically* add those downstream > dependencies to packages that depend on the library unless the > dependencies were explicitly

Re: AppStream Re: Depends/Recommends from libraries

2017-03-10 9:05 GMT+01:00 Rebecca N. Palmer : > On 10/03/17 00:10, Jeremy Bicha wrote: >> >> I think a lot of those appstream installs are from KDE and GNOME which >> install plasma-discover and gnome-software by default. > > Do those things display AppStream "packages

Re: Depends/Recommends from libraries

On Thu, 09 Mar 2017 at 17:52:05 -0500, Marvin Renich wrote: > If more upstreams were careful to use dynamic loading in these > situations, it would be less of a problem. In a perfect world, the > solution would be for foo's maintainer to convince upstream to switch to > dynamic loading. (For

Re: Depends/Recommends from libraries

Dear Ian, Le 09/03/2017 à 18:39, Ian Jackson a écrit : > Thibaut Paumard writes ("Re: Depends/Recommends from libraries"): >> There are quite legitimate uses for dependencies or recommendations in >> libraries. For instance, tne library that I maintain (libgyoto) has the

Re: AppStream Re: Depends/Recommends from libraries

On 10/03/17 00:10, Jeremy Bicha wrote: I think a lot of those appstream installs are from KDE and GNOME which install plasma-discover and gnome-software by default. Do those things display AppStream "packages related to this hardware" by default? (beignet-opencl-icd isn't a valid test because

Re: Depends/Recommends from libraries

Marvin Renich writes: > If libbar-dev documents that it requires bar-daemon (and under what > circumstances, if appropriate), but libbar does not declare the Depends, > then it becomes the Debian maintainer of foo who decides to add an > appropriate Depends, Recommends, or

Symbol specific dependencies (was Re: Depends/Recommends from libraries)

Hi! On Thu, 2017-03-09 at 17:29:09 +, Ian Jackson wrote: > I think the right way to solve this problem is to declare that: […] > * If a library needs or wants additional software installed, >if and when functions in that library are called, this >should be documented in the

Re: AppStream Re: Depends/Recommends from libraries

On Thu, Mar 9, 2017 at 6:23 PM, Rebecca N. Palmer wrote: > When beignet-opencl-icd added AppStream metadata (black line in [1]), there > was no noticeable increase in its installs. As it's for popular hardware I think a lot of those appstream installs are from KDE and

AppStream Re: Depends/Recommends from libraries

appstream itself is installed on ~60% of sid/stretch desktops [0], but isenkram on only ~5% (and most of those are the -cli version). When beignet-opencl-icd added AppStream metadata (black line in [1]), there was no noticeable increase in its installs. As it's for popular hardware (~33% of

Re: Depends/Recommends from libraries

On Thu, 2017-03-09 at 10:19 -0800, Russ Allbery wrote: > > I think this would be a great way of introducing spurious bugs in our > distribution from people who don't happen to read the README file and > miss > dependencies they actually need because they're used to Debian > properly > picking up

Re: Depends/Recommends from libraries

* Russ Allbery [170309 13:19]: > I think this would be a great way of introducing spurious bugs in our > distribution from people who don't happen to read the README file and miss > dependencies they actually need... I think you are missing Ian's meaning. Currently foo Depends

Re: Depends/Recommends from libraries

Adam Borowski writes: > What's wrong in the current state is that it looks only from the point > of view of the library: libwrap1 is useless without tcpd, thus it's > natural for it to have an elevanted severity. But that dependency is > wrong from a more global point of

Re: Depends/Recommends from libraries

Andrey Rahmatullin writes: > On Thu, Mar 09, 2017 at 12:22:17PM -0800, Russ Allbery wrote: >> Sure, but hopefully we find and report those as bugs. I personally run >> without recommends on Debian unstable on several different types of >> systems and report these problems

Re: Depends/Recommends from libraries

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote: > Jonas Smedegaard writes: > > Quoting Russ Allbery (2017-03-09 04:24:09) > > >> In general, I don't want to see us place too many restrictions on > >> Recommends. If you don't want additional helpful programs,

Re: Depends/Recommends from libraries

On Mar 9, 2017 12:22 PM, "Russ Allbery" wrote: Sure, but hopefully we find and report those as bugs. I personally run without recommends on Debian unstable on several different types of systems and report these problems whenever I run into them. I'm in this same boat. I

Re: Depends/Recommends from libraries

On Thu, Mar 09, 2017 at 12:22:17PM -0800, Russ Allbery wrote: > >> If you don't want possibly unused software installed, we have a > >> supported mechanism for that: disable automatic installation of > >> Recommends. > > > Which explodes from time to time, like when ntpdate and ntpd only > >

Re: Depends/Recommends from libraries

Andrey Rahmatullin writes: > On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote: >> If you don't want possibly unused software installed, we have a >> supported mechanism for that: disable automatic installation of >> Recommends. > Which explodes from time to time,

Re: Depends/Recommends from libraries

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote: > If you don't want possibly unused software installed, we have a supported > mechanism for that: disable automatic installation of Recommends. Which explodes from time to time, like when ntpdate and ntpd only recommended lockfile-progs

Re: Depends/Recommends from libraries

On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote: > Well, I strongly disagree with you. I think this would take things in the > wrong direction; I like that software is fully useful when Recommends are > enabled at the cost of some bloat. > > If you don't want possibly unused

Re: Depends/Recommends from libraries

Ian Jackson writes: > I think the right way to solve this problem is to declare that: > * When a library package is installed, the Depends and Recommends >of the library should be appropriate on the assumption that: > - the library package is only

Re: Depends/Recommends from libraries

Jonas Smedegaard writes: > Quoting Russ Allbery (2017-03-09 04:24:09) >> In general, I don't want to see us place too many restrictions on >> Recommends. If you don't want additional helpful programs, disable >> installing Recommends by default. I think it's very odd to worry

Re: Depends/Recommends from libraries

Russ Allbery writes ("Re: Depends/Recommends from libraries"): > I feel like the problem here is that people are failing to fix bugs in > their packages (unnecessary dependencies on libraries that have heavy > dependencies), No. The problem is that for an ordinary library,

Re: Depends/Recommends from libraries

Thibaut Paumard writes ("Re: Depends/Recommends from libraries"): > There are quite legitimate uses for dependencies or recommendations in > libraries. For instance, tne library that I maintain (libgyoto) has the > option to provide MPI paralellisation. This requires an ex

Re: Depends/Recommends from libraries

Le 08/03/2017 à 23:33, Adam Borowski a écrit : > Hi, mortals and paultag! > > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as

Re: Depends/Recommends from libraries

On Wed, Mar 08, 2017 at 11:33:21PM +, Ian Jackson wrote: > Adam Borowski writes ("Depends/Recommends from libraries"): > > I'd like to discuss (and then propose to -policy) the following rule: > > > > # Libraries which don't provide a convenient means of conditi

Re: Depends/Recommends from libraries

Quoting Russ Allbery (2017-03-09 04:24:09) > Adam Borowski writes: > > > I'd like to discuss (and then propose to -policy) the following > > rule: > > > # Libraries which don't provide a convenient means of conditionally > > # loading at runtime (this includes most

Re: Depends/Recommends from libraries

On Thu, Mar 9, 2017 at 11:48 AM, Michael Biebl wrote: > out of the box. Unfortunately we don't have a well supported mechanism > which would install such hardware-enablement packages when the hardware > is plugged in. Is the AppStream hardware support stuff not well supported in the desktops?

Re: Depends/Recommends from libraries

Am 09.03.2017 um 04:24 schrieb Russ Allbery: > Adam Borowski writes: > >> I'd like to discuss (and then propose to -policy) the following rule: > >> # Libraries which don't provide a convenient means of conditionally loading >> # at runtime (this includes most libraries for

Re: Depends/Recommends from libraries

Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Adam Borowski writes ("Depends/Recommends from libraries"): >> I'd like to discuss (and then propose to -policy) the following rule: >> >> # Libraries which don't provide a convenient means of

Re: Depends/Recommends from libraries

Adam Borowski writes: > I'd like to discuss (and then propose to -policy) the following rule: > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as C), SHOULD > # NOT declare a

Re: Depends/Recommends from libraries

Adam Borowski wrote: > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as C), SHOULD > # NOT declare a "Depends:" or "Recommends:"

Re: Depends/Recommends from libraries

Adam Borowski writes ("Depends/Recommends from libraries"): > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for langua

Depends/Recommends from libraries

Hi, mortals and paultag! I'd like to discuss (and then propose to -policy) the following rule: # Libraries which don't provide a convenient means of conditionally loading # at runtime (this includes most libraries for languages such as C), SHOULD # NOT declare a "Depends:" or "Recommends:"