On 29 January 2014 04:32, Petr Rockai <m...@mornfall.net> wrote: > Jan Malakhovski <o...@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 _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev