tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/security/gnupg2



  [previous discussion about PKGREVISION in changing gnupg options]

(This turned into an essay on the theory of options, so sending it more
widely.)

I am curious why you started down this path - it's quite likely I am
missing something.

Multiple separate things to think about:

  Sometimes packages find things and use them, even if the bl3 line is
  not present.  I checked one of my systems, and gpg2 had zlib and bz2
  linked in (from NetBSD base), found by configure.  The base system is
  not hidden by bl3.

  Options are useful, but they are also troublesome.  Having an option
  only makes sense if there are people that will want it each way, and
  the benefit to them outweighs the pain and complexity of the option.

  Often plugins are better than options, but harder.  (Doesn't seem
  useful here.)

  Remember that users of standard binary package do not get to choose
  options.

  When adding an option to do soemthing new and truly optional, just add
  it to SUPPORTED, and don't PKGREVISION++.  This is usually
  uncontroversial.  Adding it to SUGGESTED means everyone has the code
  and the dependencies, which can range from trivial (zlib) to
  unbearable (qt).

  Compression in gnupg might be controversial, but doing what the IETF
  says shouldn't be.  I gather there was resistance to adding bzip2 to
  the IETF standard.  So I'm not sure what problem is being solved, and
  for who.  The commit message is a good place to explain this :-)
  Reading the rfc4880bis draft at
    https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/?include_text=1
  it seems zip is SHOULD and the others are MAY.  Also, compression
  algorithms can only be used if noted in the recipient's key.

  (I am assuming gnupg works with zip, because that's the longstanding
  default in the standard.)

  Given the above, the questions are:
    - what do the gnupg build instructions recommend?
    - do other implementations cope with zlib/bzip2?
    - do other packaging systems enable zlib/bzip2?
    - is zlib/bzip2 actually in use, in that keys have them as preferences?
      (FWIW, my own key has zlib in the prefs)

    - how much does it hurt in terms of dependencies to add zlib?
    - to add bzip2?  (not much on NetBSD, since it's in base)

And yes, it really is good to think through all of this, because
maintaining pkgsrc is about making choices for others, who don't have
the time/expertise to figure everything out.  Typically the package
maintainer is the expert in the subject.


So, having found out that gnupg was linking in libz and libbz2 from
base, but not having it declared, we have a situation where using the
algorithms is normal, but on an OS that lacks them in base, they might
not get used.  Given that they are lightweight compared to gnupg2
itself, I think the right thing to do is just to add the bl3 lines to
Makefile and not have them in options.  And probably PKGREVISION++ for
the case that some platform somewhere didn't have it in base and thus
the binary package will change on that platform.


Home | Main Index | Thread Index | Old Index