[Nix-dev] Why having releases if you break things in it often

[Freddy Rietdijk]

> So except you want security updates you dont have to update your system? I
think automated tests could fix that...
>
> something like systemctl status flexget | grep running or something like
that.

Packages and modules preferably have tests. There were a couple of packages
broken because of the update, and if I recall correctly none had tests...

On Mon, Jan 23, 2017 at 4:09 PM, Stefan Huchler <stefan.huchler at mail.de>
wrote:

> Hello Freddy,
>
> yes I think that html5lib thing would it be. So it was at least a
> security fix, so you dont just update stuff to update it, which would
> make releases pretty useless concept :)
>
> So except you want security updates you dont have to update your system?
> I think automated tests could fix that...
>
> something like systemctl status flexget | grep running or something like
> that.
>
> Of course you cant write a test for every cornercase, but that bug seems
> pretty obvious and easy to reproduce (install/upgrade flexget).
>
> Sorry I formulated that message a bit trollish, but just wanted to learn
> why how releases are done in nixos.
>
> Also a hint why list-derivations and boot options in grub dont are the
> same would be interesting? Maybe when I run gc or optimise they vanish
> from grub?
>
> Stefan
>
>
> Freddy Rietdijk <freddyrietdijk at fridh.nl> writes:
>
> > Hi Stefan,
> >
> > Regarding flexget. There were some security issues with an (indirect)
> dependency, html5lib, and thus
> > html5lib was upgraded. Maybe that broke flexget, I don't know.
> >
> > The main issue is just a lack of maintainers. It's relatively
> straightforward to add a package to Nixpkgs, but
> > maintaining a package set this size that also keeps growing is becoming
> increasingly harder.
> >
> > Freddy
> >
> > On Mon, Jan 23, 2017 at 10:07 AM, Stefan Huchler <stefan.huchler at mail.de>
> wrote:
> >
> >  So because I dont need always newest versions on all of my boxes, I
> >  selected the 16.xx chhannel.
> >
> >  There are here and there some minor issues as example kodi here and
> >  there crashes maybe 1-3 times a week. Could be extentions or something.
> >
> >  For that and other reasons I update here and there all few weeks maybe
> >  the maschine.
> >
> >  So one advantage of course is that if I notice that something does not
> >  work I can boot a old configuration, so I dont have to deal with some
> >  updates that broke stuff or rollback.
> >
> >  But I wonder how you can break relativly often stuff (at the moment
> >  there seems to be a python dependency problem with flexget, that makes
> >  the daemon crash), in a "stable" release channel.
> >
> >  I mean if I use debian, and stick to my "channel"/release, normaly
> >  nothing breaks, as long as I use only their package installer, pip
> >  updates of course broke stuff. If I use fedora, well I get maybe some
> >  upstream changes like new kernel versions, but normaly they brake also
> >  nothing.
> >
> >  So if "stable" channel makes updates that are not needed (the older
> >  version of flexget works fine), whats the point or the criterias of
> >  those releases? I could then just use the newest version, if I have to
> >  relay on rollback / boot old versions anyway, I dont really see the
> >  point of "stable" channels.
> >
> >  I had pretty good experiences with using the rolling channel, but had
> >  many times break stuff in the stable channel.
> >
> >  Also the tools around generations / boot-generations is very confusing,
> >  why do I have 3 4 options in the nix-env --list-generation overview but
> >  20 in the boot menu.
> >
> >  But thats a 2nd different issue I guess.
> >
> >  Just wonder what your policies are.
> >
> >  Other stuff that broke on me in the past, was latex packages as example.
> >
> >  _______________________________________________
> >  nix-dev mailing list
> >  nix-dev at lists.science.uu.nl
> >  http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20170123/5a579977/attachment.html>