Re: [Nix-dev] Maintainership
And when to remove unmaintained lines? After yet another year or so? unmaintained "git-hash" "package-name" "2014-jan" ^^ so that you know when to remove that line? ^ you may want to catch the install by name case ^^ you cannot instert it, you have to use the git hash before that one Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On 01/29/2014 11:28 PM, Jan Malakhovski wrote: That's clever. And not too much pain. I could handle that in case my package got removed. I recommend using git "log -G regexp" to search the whole history if you fail to find something. Currently it's just a matter of several seconds on our repo and reasonable HW. With this I see little need for keeping those stubs (for real use one should also preserve name). Whatever the way, we need to somehow indicate quality of the packages. There's lots of stuff that don't build for many months, or with security holes... Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On Wed, 29 Jan 2014 11:44:40 -0800 James Cook wrote: > 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 And restoring a package would mean reverting the patch and then fixing the expression. Also this would probably mean less merge conflicts then rebasing my branch with reverts and fixes on top of nixpkgs since the line with my_package would still be there and would split any changed chunks around it. That's clever. And not too much pain. I could handle that in case my package got removed. Some of the people here don't want to drag all the old broken stuff and want to force maintainers update their stuff so that at least the expressions evaluate, that's understandable. I fear for the duplication of work. This 'unmaintained' derivation should make everyone happy. Cheers, Jan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
On 29 January 2014 04:32, Petr Rockai wrote: > Jan Malakhovski 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
Re: [Nix-dev] OCaml
2014-01-29 Moritz Ulrich > > I agree with a cleanup of the OCaml stuff - there are many versions in > nixpkgs, and I wonder which of these are really necessary. > We have ocaml 3.08.0 which is used only for qcmm. I don't know exactly what qcmm is (a C-- compiler?). But apparently is something that has not been touched for a long time now (2006?) and there is no meta/maintainership on it. Both can be dropped without harm, I guess. Also ocaml 3.10.0 is not used anywhere in nixpkgs. Finally ocaml 3.11.2 is used for matita (the theorem prover). I think we can keep it until a more updated and stable version of matita is available. Summarising: For now I propose to remove the following from nixpkgs qcmm ocaml_3_08_0 and ocamlPackages_3_08_0 ocaml_3_10_0 and ocamlPackages_3_10_0 Marco ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
>Michael Raskin <7c6f4...@mail.ru> writes: >> Somehow, whenever updates of packages I care about were broken, it was >> a simple mistake that was easy to fix separately… I think this scenario >> is overly pessimistic. > >Well, depends on your point of view. If you only care about a few >packages for your personal use, it's one thing, when you deploy an I care about a few hundreds packages that I want to have installed, and a few tens of them are something I use constantly. >installation with twenty users it's entirely different. You run into the >need to fix packages that you don't personally use or aren't very >familiar with, and even if you figure out a fix, it is unlikely to be >entirely correct. > >Being able to consult someone who understands both nix(os) *and* the >package in question in a timely fashion would make fixing such problems >much easier, and even somewhat less likely to be required. Improving quality of individual packages = reducing count of packages in the short run. So it's better to have a dump for non-Hydra-worthy packages… >> In general, one can expect that the amount of time maintainers spend on >> their packages will not change too much whatever policy change you >> propose. There are some packages that I want to have installed but don't >> care about versions, so the question is not whether I will maintain them >> well but whether I will keep them in configurations/ or nixpkgs/. > >Well, I expect that if the tools make it easy to see whom to contact >about a particular package, maintainers will see more engagement from >their users. That alone can work to make them more active, and can give Or just burn out… Hopefully only w.r.t. NixPkgs and only temporarily. >them valuable feedback/new knowledge about how the package is/can be >used. It also makes it less likely they break use-cases in the future if >they are familiar with them. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Michael Raskin <7c6f4...@mail.ru> writes: > Somehow, whenever updates of packages I care about were broken, it was > a simple mistake that was easy to fix separately… I think this scenario > is overly pessimistic. Well, depends on your point of view. If you only care about a few packages for your personal use, it's one thing, when you deploy an installation with twenty users it's entirely different. You run into the need to fix packages that you don't personally use or aren't very familiar with, and even if you figure out a fix, it is unlikely to be entirely correct. Being able to consult someone who understands both nix(os) *and* the package in question in a timely fashion would make fixing such problems much easier, and even somewhat less likely to be required. > In general, one can expect that the amount of time maintainers spend on > their packages will not change too much whatever policy change you > propose. There are some packages that I want to have installed but don't > care about versions, so the question is not whether I will maintain them > well but whether I will keep them in configurations/ or nixpkgs/. Well, I expect that if the tools make it easy to see whom to contact about a particular package, maintainers will see more engagement from their users. That alone can work to make them more active, and can give them valuable feedback/new knowledge about how the package is/can be used. It also makes it less likely they break use-cases in the future if they are familiar with them. Of course, having nix-env or somesuch list maintainers, and making it possible to file issues with individual packages (as opposed to just making a generic issue in github) would help with those things as well. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
>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. Somehow, whenever updates of packages I care about were broken, it was a simple mistake that was easy to fix separately… I think this scenario is overly pessimistic. In general, one can expect that the amount of time maintainers spend on their packages will not change too much whatever policy change you propose. There are some packages that I want to have installed but don't care about versions, so the question is not whether I will maintain them well but whether I will keep them in configurations/ or nixpkgs/. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] OCaml
On Wed, Jan 29, 2014 at 11:23 AM, Lluís Batlle i Rossell wrote: > As long as mldonkey works, fine for me. :) If it doesn't, mldonkey can still use 3.12.*. I agree with a cleanup of the OCaml stuff - there are many versions in nixpkgs, and I wonder which of these are really necessary. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Jan Malakhovski 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. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Thomas Bereknyei writes: > That almost sounds like an "unstable" channel. Unstable and unmaintained are two very different things. > Rather than removing unmaintained packages, can we make them available as > a > separate, opt-in channel? I'd say that is an option, but if the unmaintained pile contains important software and basically everybody needs to enable it, we are not much better off -- we'll still get a lot of breakage every time we update the system and even up-to-date systems will likely sport many vulnerabilities. Not everyone is happy to rely on security by obscurity of NixOS, and if it becomes more widespread it could become an easy attack target. I imagine that non-NixOS installations of nixpkgs have a different set of trade-offs though. -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Alex Berg's message of Wed Jan 29 03:57:56 +0100 2014: > Rather than removing unmaintained packages, can we make them available as a > separate, opt-in channel? Then they will bitrot even faster - because you have to test much more. It would be possible, I've been using kind of overlays for a long time (for haskell and ruby packages packaged "my automatic style") But also see below, git history will be available always .. @Jan Malakhovski >For what it worth, I think unmaintained packages should not be removed >just for the sake of it, especially when/if their nix-expressions are >nontrivial. Don't forget that history will always be accessible by using git search. But I agree that its easy to miss that. Its non trivial to estimate how much complicated packages (let's say openoffice/libreoffice for instance) also change while packages are broken. In the open office / libre office case open office was broken too, but the fix was not to fix open office but to switch to libre office. There are so many reasons that it does make sense to remove packages after some time (maybe 6-12 month) which is why its important to declarate since when they were broken. At least that's what I think. The more interesting question is whether we should try to keep all tarballs mirrored, so that you at least have a chance to install the old versions which worked once .. - Again nice users statistics would help determining which source archives to keep. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] OCaml
On Wed, Jan 29, 2014 at 09:04:04AM +0100, Marco Maggesi wrote: > Presently, the ocaml attribute in all-packages.nix points to 3.12.1 which > is rather old now, dating back to 2011. > I propose to make OCaml 4.01.0 the default version of OCaml. > The OCaml 4.xx series is almost two years old now and OCaml 4.01.0 is > already the default version installed (i.e. with nix-env -i ocaml) since > some time now. As long as mldonkey works, fine for me. :) Thank you, Lluís. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] OCaml
Hi, Presently, the ocaml attribute in all-packages.nix points to 3.12.1 which is rather old now, dating back to 2011. I propose to make OCaml 4.01.0 the default version of OCaml. The OCaml 4.xx series is almost two years old now and OCaml 4.01.0 is already the default version installed (i.e. with nix-env -i ocaml) since some time now. I just sent a pull request for this. Marco ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
