On Thu, 2019-12-05 at 18:51 +0100, Leo Prikler wrote:
Toggle quote (49 lines)
> Am Donnerstag, den 05.12.2019, 09:53 -0700 schrieb Jesse Gibbons:
> > On Wed, 2019-12-04 at 13:11 +0100, Leo Prikler wrote:
> > > Hi Guix,
> > >
> > > I recently discovered, that Evolution would complain about a
> > > missing
> > > GPG whenever it encounters a signed message. For the record, I've
> > > only
> > > installed evolution-data-server in the operating-system and
> > > evolution
> > > itself inside my user profile and not installed gpg in either
> > > place,
> > > thus causing this issue. Would it make sense to make gpg an input
> > > to
> > > evolution and hardcode the path in the source? Or would it perhaps
> > > be
> > > better to have it as propagated input? WDYT?
> > >
> > > Regards,
> > > Leo
> > >
> > >
> > >
> > >
> > Guix complains that it cannot find gpg when I call "guix import gnu
> > <package>". But unless I'm using a function of guix that depends on
> > gpg,
> > guix is not broken, so gpg is not an input or propagated input of
> > guix. I
> > think we have the same situation here. Evolution is functional
> > without GPG,
> > and handles itself fairly well when gpg is not found.
> >
> > Try installing gpg locally and see if it stops complaining. If so, we
> > have a
> > solution. If not, we should consider adding GPG as a propagated input
> > to
> > Evolution.
> That does fix the problem itself, but I personally believe there should
> be a better way of handling "optional" inputs -- "optional" because in
> at least some if not many cases, people would expect them to exist.
> Guix' emacs has imagemagick as input for instance (even though it is
> optional) and a separate emacs-minimal exists as the version without it
> and other optional inputs. I think this pattern could be applied more
> broadly.
>
> Regards,
> Leo
>
There are a lot of optional inputs to packages with minimal versions like
git and emacs, and a lot of them are used by guix itself for bootstrapping
and building other packages.
I see my logic was faulty. Some of the packages I contriubted list optional
inputs, and the people who committed them added comments saying we should
plan on packaging those optional inputs and adding them as inputs. Perhaps
your first suggestion, being to add gpg as an input or propagated input to
evolution, is indeed the best solution.
This brings us back to the original question, which approach is better? I am
not familiar enough with guix security features to make a proper conclusion,
but I can try anyway. I think adding gpg as a propagated input to evolution
is better because it garuntees evolution will use the most recent version of
gpg when gpg is updated. However, if a user uses gpg not exclusively for
evolution, but gets it by installing evolution, then when evolution is
removed the user will lose gnupg. Though that would be mostly the user's
problem, propagating inputs is a side-effect. On the other hand, if gnupg is
an input, when gnupg is updated and rebuilt, evolution must be rebuilt. I do
not know how guix determines if grafts should be applied, so I do not know
if grafting will prevent this issue.
I would like to see what the guix maintainers think before I make a patch,
but there's nothing stopping you from making such a simple patch and sending
it to this bug thread.
