[Nix-dev] Maintainership

James Cook james.cook at utoronto.ca
Wed Jan 29 20:44:40 CET 2014


On 29 January 2014 04:32, Petr Rockai <me at mornfall.net> wrote:
> Jan Malakhovski <oxij at oxij.org> writes:
>> * First, this "remove unmaintained" policy discourages adding new
>> packages to the public nixpkgs by users that are unable to maintain
>> stuff. In the example above, I would better store the package in my
>> own branch than risk it being unexpectedly removed. This would
>> probably imply duplication of work in case somebody else will want to
>> have it at some later point. I wouldn't search all the nixpkgs' forks
>> for a possibility that somebody already has an expression for this
>> package.
>
> It is a trade-off. Broken packages can be more overhead than duplication
> of work. If you make a package that works for you, push it to nixpkgs
> and abandon it, the next person will find it broken for his purpose, fix
> it and in the process break it for you. You will both spend time
> debugging the package. If one of the two users was a maintainer, the
> other could come to him and they can figure out something that works for
> both. If there is no maintainer and you update once in a while, you can
> end up ping-ponging fixes and counterfixes.
>
>> I would rather drop this "remove unmaintained" altogether, at least
>> for current requirements for being a maintainer (especially about the
>> "timely fashion"). Marking unmaintained (or even better: unmaintained
>> and potentially exploitable (which I would define as: it's a daemon or
>> some other package uses it)) packages broken and notifying
>> contributors about this fact looks okay.
>
> Even things that are marked as broken involve cognitive overhead when
> working on nixpkgs. They clutter up the source, often use outdated
> idioms, they hold up or complicate changes in support code. It's like a
> closet, it's hard to get at the things you actually use when it's full
> of junk.
>
> As for exploitable, that's an extremely conservative approach you
> suggest. I'm wondering if a remote code execution vulnerability in your
> browser or e-mail client is of no concern to you. :-) Or a PDF reader?
> Flash plugin? There have been countless security breaches due to bugs in
> non-daemon, leaf packages.

How about deleting the expression but leaving a note about where to
find it?  For example, in all-packages.nix:

  my_package = unmaintained "0123abcd";

and then

  $ nix-env -i my-package
  my-package was deleted because it is unmaintained.  If you would
like to restore it, the last commit that contained the expression was
0123abcd....

James


More information about the nix-dev mailing list