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 us
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 l
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 example, I&
* 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 ha
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
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").
Than
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
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:
https://lists.debian.org/debian-devel/2015/02/ms
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 "Depe
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'
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 unblock for stretch at this
poin
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 library unless the
>> dep
* 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 convince upstream
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 suppre
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 related to this hardware" by
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 cont
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
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
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 Suggests for bar-daemon
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 /usr/share
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 GNOME which
install plasma-
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 s
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 s
* 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 libbar,
and libbar
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 view. That's why I'm pr
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 whenever I run into the
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, disable
> >> installi
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 disable installing rec
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
> > recom
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, like when ntpdate an
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
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 software
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 installed because it is the dormant
>
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
>> about bloat
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,
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
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 C)
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 conditionally loading
> > # at runtime
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 libraries for languages
> >
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?
ht
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 languages such as C),
Ian Jackson 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 conditionally loading
>> # at runtime (this includes most libraries for languages
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 "Depends:" or "Recommends:"
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
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 languages such as C), SHOULD
> # NOT
45 matches
Mail list logo
