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
^^ yo
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
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
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 t
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
>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
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 you
>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
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.
___
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
>
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 unmaintai
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 overla
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
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
14 matches
Mail list logo
