On Tue, Oct 23, 2018 at 04:40:34PM +, Ivan Shmakov wrote:
> > Wouter Verhelst writes:
> > On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> > On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
>
> […]
>
> >>> I think the prerequisite for making a change
On Fri, Oct 26, 2018 at 11:15:36AM -0400, Marvin Renich wrote:
Sure. But that requires the admin to build a package and deal with
version number issues related to that package. E.g. A Depends: B, then
later, A Depends: B and A Breaks: B < someversion. The admin simply
wants to not install B an
On Fri, Oct 26, 2018 at 08:38:01AM -0400, The Wanderer wrote:
I suppose, on consideration, that this boils down to me being a grumpy
pedant about language - which isn't necessarily helpful in a discussion
that's more related to technical merits
It's useful. You're pointing out bugs in our polic
* Holger Levsen [181026 10:45]:
> On Fri, Oct 26, 2018 at 09:24:17AM -0400, Marvin Renich wrote:
> > Using Depends instead of Recommends actually _prevents_ the admin from
> > being able to choose.
>
> you know about the equivs package, do you?
Sure. But that requires the admin to build a pack
On Fri, Oct 26, 2018 at 09:24:17AM -0400, Marvin Renich wrote:
> Using Depends instead of Recommends actually _prevents_ the admin from
> being able to choose.
you know about the equivs package, do you?
--
cheers,
Holger
* The Wanderer [181026 08:38]:
> On 2018-10-26 at 00:51, Russ Allbery wrote:
> > You choose the strongest relationship that is applicable.
>
> I'm not sure that's clear from the given definitions, nor that it should
> necessarily hold. Is there any statement which would make that explicit?
> I ha
* Russ Allbery [181026 00:52]:
> I don't know why you would expect otherwise? That seems entirely natural
> and expected given that Depends is a stronger relationship than
> Recommends, and therefore is naturally a subset of the things that would
> qualify as Recommends.
[As The Wanderer said, I
On 2018-10-26 at 00:51, Russ Allbery wrote:
> The Wanderer writes:
>
>> On 2018-10-25 at 20:00, Russ Allbery wrote:
>
>>> The Depends field should be used if the depended-on package is
>>> required for the depending package to provide a significant
>>> amount of functionality.
>
>> This does
Quoting Russ Allbery (2018-10-26 02:00:24)
> But I think it's simply incorrect to say that libgpgme11 is in any way
> doing something wrong given what Policy says right now. This
> *clearly* meets the definition of Depends as currently stated in
> Policy.
I agree that current behaviour of libg
The Wanderer writes:
> On 2018-10-25 at 20:00, Russ Allbery wrote:
>> The Depends field should be used if the depended-on package is
>> required for the depending package to provide a significant amount of
>> functionality.
> This does not actually seem to conflict with the "would be
On 2018-10-25 at 20:00, Russ Allbery wrote:
> Marvin Renich writes:
>
>> I certainly agree with you that 99.9% is clearly a wrong number for
>> this. However I disagree that even 0.1% justifies using a different
>> definition for Recommends than policy gives.
>
> libgpgme11 is not doing that.
Marvin Renich writes:
> I certainly agree with you that 99.9% is clearly a wrong number for
> this. However I disagree that even 0.1% justifies using a different
> definition for Recommends than policy gives.
libgpgme11 is not doing that. The library is literally unusable for its
actual techni
* Wouter Verhelst [181025 08:26]:
> On Tue, Oct 23, 2018 at 05:04:11PM +0200, Vincent Lefevre wrote:
> > But a Depends or Recommends on gnupg
> > will annoy 99.9% of the users;
>
> Err, no.
>
> That number makes the assumption that all users who have something
> installed that they don't end up
On Tue, Oct 23, 2018 at 05:04:11PM +0200, Vincent Lefevre wrote:
> On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote:
> > On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
> > > It can be argued that libgpgme11 does not “provide a significant
> > > amount of functionality” (7.2) with
On 2018-10-24 10:33:30 +0100, Jonathan Dowland wrote:
> That is sort-of what is happening for neomutt (20171215+dfsg.1-1)
> at least, it reports
>
>sh: 1: gpg: not found
>
> There's room for improvement there. mutt (1.9.2-1) is worse
>
>Error: verification failed: Unsupported protocol
>
On Wed, Oct 24, 2018 at 03:40:12PM +, Ivan Shmakov wrote:
> What are the values of the crypt_use_gpgme setting in each case?
> Could it be that mutt and neomutt actually have different defaults
> (one using gpg(1) directly and the other using GPGME) here?
According to codesear
On Wed, Oct 24, 2018 at 03:40:12PM +, Ivan Shmakov wrote:
What are the values of the crypt_use_gpgme setting in each case?
Could it be that mutt and neomutt actually have different defaults
(one using gpg(1) directly and the other using GPGME) here?
I suspect so; but
> Jonathan Dowland writes:
> On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote:
> On Oct 23, Tollef Fog Heen wrote:
>>> Wouldn’t it make more sense for mutt to just go «oh, no GPG
>>> installed, let’s note that there are signatures here, but they
>>> can’t be verified,
On Wed, Oct 24, 2018 at 01:11:47PM +0200, Marco d'Itri wrote:
sh: 1: gpg: not found
This looks like a very clear error message to me.
It's certainly clearer than the other one, but it's not good enough
IMHO, we should have something that unambigously means "you need to
install exactly this
On Oct 24, Jonathan Dowland wrote:
> That is sort-of what is happening for neomutt (20171215+dfsg.1-1)
> at least, it reports
>
>sh: 1: gpg: not found
This looks like a very clear error message to me.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote:
On Oct 23, Tollef Fog Heen wrote:
Wouldn't it make more sense for mutt to just go «oh, no GPG installed,
let's note that there are signatures here, but they can't be verified,
since there's no GPG installed on the system» and let the
Ian Jackson writes:
> Russ Allbery writes ("Re: no{thing} build profiles"):
>> Minimal installation size is *not* the only goal here. Ease of use and
>> lack of surprise is important to. Personally, I'd much rather have
>> numerous unused packages installe
On Oct 23, Tollef Fog Heen wrote:
> > I have sympathy with that position, but in which case PGP should be
> > disabled by default in the /etc/Muttrc files too.
> Wouldn't it make more sense for mutt to just go «oh, no GPG installed,
> let's note that there are signatures here, but they can't be v
]] Jonathan Dowland
> On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote:
> >PGP-signed mail is an highly advanced feature, so I do not think that it
> >is unreasonable to expect from users who want to use it to also install
> >gnupg.
> …
> >No: it is also TOTALLY POINTLESS to even just
> Wouter Verhelst writes:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
[…]
>>> I think the prerequisite for making a change like this would be for
>>> the library to be able to surface this transiti
On 2018-10-23 17:01:04 +0200, Wouter Verhelst wrote:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> > That would be a bad idea -- we don't want gratuitous dependencies
> > all around. Just because I use xfce doesn't mean I want a daemon
> > for some old kinds of iApple iJunk
>
On 2018-10-23 16:55:00 +0200, Wouter Verhelst wrote:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > * Sune Vuorela [181021 06:05]:
> > > On 2018-10-21, Jonas Smedegaard wrote:
> > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at
> > > > all:
> > > >
Russ Allbery writes ("Re: no{thing} build profiles"):
> Minimal installation size is *not* the only goal here. Ease of use and
> lack of surprise is important to. Personally, I'd much rather have
> numerous unused packages installed than to have something break in an
&g
On Tue, Oct 23, 2018 at 05:01:04PM +0200, Wouter Verhelst wrote:
> > That would be a bad idea -- we don't want gratuitous dependencies all
> > around. Just because I use xfce doesn't mean I want a daemon for some old
> > kinds of iApple iJunk
>
> Why not? What does it cost you, other than a few b
On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote:
> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
> > It can be argued that libgpgme11 does not “provide a significant
> > amount of functionality” (7.2) without gnupg.
>
> It won't function at all without gnupg.
That's pointless
On Tue, Oct 23, 2018 at 04:55:00PM +0200, Wouter Verhelst wrote:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > * Sune Vuorela [181021 06:05]:
> > > On 2018-10-21, Jonas Smedegaard wrote:
> > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at
> > > > al
On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> > Adam Borowski writes:
> >
> > > Thus, I'd re-propose a Policy change that was mentioned in multiple
> > > threads in the past:
> >
> > > "A runtime library should no
On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> * Sune Vuorela [181021 06:05]:
> > On 2018-10-21, Jonas Smedegaard wrote:
> > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all:
> > > As a library it cannot possibly declare how tight a relationship to
> >
On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote:
PGP-signed mail is an highly advanced feature, so I do not think that it
is unreasonable to expect from users who want to use it to also install
gnupg.
…
No: it is also TOTALLY POINTLESS to even just automatically verify
received ema
[I'm subscribed; please do not CC me.]
* Matthias Klumpp [181022 14:18]:
> Because having a real dependency eliminates another source of bugs.
> The library will throw weird (for unexperienced end-users) errors and
> they have to hunt down a solution for why something isn't working as
> they expe
On Oct 23, Jonathan Dowland wrote:
> Both of Depends and Recommends in this case have drawbacks. It's a
> matter of weighing them up and considering their likelyhoods on a case
> by case basis. In this case, the maintainer must weigh the experience of
> users who may install mutt without gnupg an
Quoting Jonathan Dowland (2018-10-23 11:06:15)
> On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
> >I'm going to use the neomutt → libgpgme → gnupg as an example, but
> >this applies as well to any other case where someone has a legitimate
> >use for installing one package without
* Russ Allbery [181022 16:23]:
> Minimal installation size is *not* the only goal here. Ease of use and
> lack of surprise is important to.
Then don't disable Recommends in apt preferences.
> Personally, I think people in this thread are too worried about trying to
> remove as many packages fro
On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Personally, I think people in this thread are too worried about trying to
> remove as many packages from their system as possible and not worried
> enough about a straightforward user experience.
yep.
--
cheers,
Holger
---
On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
This keeps getting repeated in this thread in spite of the fact that
multiple people have stated that having libgpgme installed without gnupg
is useful in a very reasonable scenario.
The scenario you describe, where the utility of t
On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
> Adam Borowski writes:
>
> > Thus, I'd re-propose a Policy change that was mentioned in multiple
> > threads in the past:
>
> > "A runtime library should not Depend: or Recommend: on any packages than
> > other libraries or dormant d
Adam Borowski writes:
> Thus, I'd re-propose a Policy change that was mentioned in multiple
> threads in the past:
> "A runtime library should not Depend: or Recommend: on any packages than
> other libraries or dormant data, unless the library or its programming
> language provides a convenient
Am Mo., 22. Okt. 2018 um 17:32 Uhr schrieb Marvin Renich :
>
> * Matthias Klumpp [181021 14:04]:
> > libgpgme is communicating with gnupg in the background - having
> > libgpgme without gnupg itself will render the library completely
> > unusable and break existing users of the library.
>
> This k
On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote:
> * Matthias Klumpp [181021 14:04]:
> > libgpgme is communicating with gnupg in the background - having
> > libgpgme without gnupg itself will render the library completely
> > unusable and break existing users of the library.
>
> Thi
* Matthias Klumpp [181021 14:04]:
> libgpgme is communicating with gnupg in the background - having
> libgpgme without gnupg itself will render the library completely
> unusable and break existing users of the library.
This keeps getting repeated in this thread in spite of the fact that
multiple
> Jonathan Dowland writes:
> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
>> It can be argued that libgpgme11 does not “provide a significant
>> amount of functionality” (7.2) without gnupg.
> It won’t function at all without gnupg.
As I’ve said before, havin
On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
It can be argued that libgpgme11 does not “provide a significant
amount of functionality” (7.2) without gnupg.
It won't function at all without gnupg.
However, and it seems to be a common practice in Debian, for a shared
library pa
On Sun, Oct 21, 2018 at 08:03:49PM +0200, Matthias Klumpp wrote:
> libgpgme is communicating with gnupg in the background - having
> libgpgme without gnupg itself will render the library completely
> unusable and break existing users of the library.
> Therefore, if you have something that wants lib
> Andrey Rahmatullin writes:
> On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote:
>>> "Every package must specify the dependency information about other
>>> packages that are required for the first to work correctly."
>>> Policy 3.5.
>> The gnupg package is not required fo
On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote:
> > "Every package must specify the dependency information about other
> > packages that are required for the first to work correctly." Policy 3.5.
>
> The gnupg package is not required for (neo)mutt to work
> correctly,
Am So., 21. Okt. 2018 um 18:13 Uhr schrieb Marvin Renich :
>
> * Sune Vuorela [181021 06:05]:
> > On 2018-10-21, Jonas Smedegaard wrote:
> > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all:
> > > As a library it cannot possibly declare how tight a relationship to
> > > d
On Sun, Oct 21, 2018 at 01:46:48PM -0400, Marvin Renich wrote:
> > > The proper fix is to convince upstream to dynamically link at runtime
> > > and disable some features if libgpgme is not available.
> > dlopening a dependency is bad: for example, it doesn't allow distro
> > builders to track the
]] Ivan Shmakov
> > Sune Vuorela writes:
> > On 2018-10-21, Jonas Smedegaard wrote:
> > Tollef Fog Heen writes:
>
> [I see I’ve managed to botch References: for the
> news:linux.debian.devel readers; my apologies for that.]
>
> >>> tinysshd only ships a systemd unit
* Andrey Rahmatullin [181021 13:20]:
> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
> > Semantically, Depends: declares that the package has to be
> > installed to proceed. It doesn’t specify whether the package
> > has to actually be used. Which kind of invalidates
> Andrey Rahmatullin writes:
> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
> Tollef Fog Heen writes:
>>> tinysshd only ships a systemd unit file; neomutt links against
>>> libgpgme11 which again Depends on gnupg. It’s the kind of
>>> dependencies that individual
* Andrey Rahmatullin [181021 13:16]:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > The proper fix is to convince upstream to dynamically link at runtime
> > and disable some features if libgpgme is not available.
> dlopening a dependency is bad: for example, it doesn't allow
On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
> Semantically, Depends: declares that the package has to be
> installed to proceed. It doesn’t specify whether the package
> has to actually be used. Which kind of invalidates the point.
"Every package must specify
On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> The proper fix is to convince upstream to dynamically link at runtime
> and disable some features if libgpgme is not available.
dlopening a dependency is bad: for example, it doesn't allow distro
builders to track the deps properly an
* Sune Vuorela [181021 06:05]:
> On 2018-10-21, Jonas Smedegaard wrote:
> > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all:
> > As a library it cannot possibly declare how tight a relationship to
> > declare - instead, all _consumers_ of the library must declare whether
❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
> >>> tinysshd only ships a systemd unit file; neomutt links against
> >>> libgpgme11 which again Depends on gnupg. It’s the kind of
> >>> dependencies that individually make sense,
>
> I beg to differ; I suppose (though haven’t actually tried
> Sune Vuorela writes:
> On 2018-10-21, Jonas Smedegaard wrote:
> Tollef Fog Heen writes:
[I see I’ve managed to botch References: for the
news:linux.debian.devel readers; my apologies for that.]
>>> tinysshd only ships a systemd unit file; neomutt links against
>
On 2018-10-21, Jonas Smedegaard wrote:
> I disagree that libgpgme11 should depend/recommend/suggest gnupg at all:
> As a library it cannot possibly declare how tight a relationship to
> declare - instead, all _consumers_ of the library must declare whether
> they depend/recommend/suggest gnupg.
Quoting Tollef Fog Heen (2018-10-21 10:22:56)
> ]] Ivan Shmakov
>
> > (BTW, while we're at it, could someone please explain me what
> > tinysshd [1] does need systemd for? Or why installing neomutt
> > has to invite gnupg along?)
>
> tinysshd only ships a systemd unit file; ne
]] Ivan Shmakov
> (BTW, while we're at it, could someone please explain me what
> tinysshd [1] does need systemd for? Or why installing neomutt
> has to invite gnupg along?)
tinysshd only ships a systemd unit file; neomutt links against
libgpgme11 which again Depends on gnupg.
On Sat, Oct 20, 2018 at 06:37:20PM +, Ivan Shmakov wrote:
> Now, unless I be mistaken, “build profiles,” as suggested in
> this subthread, are meant to allow for building packages with
> specific changes to their run-time library dependencies?
> Frankly, I don’t see much
> Bastian Blank writes:
> On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt writes:
>>> Should Debian also support “noalsa”, “noavahi”, “nocups”,
>>> “nopulseaudio”, “nosysvinit”, “nodbus”, “nopam”, “nowayland”,
So long as there’s su
66 matches
Mail list logo
