[Nix-dev] Package maintainer coordination problem and Nix

[Mads Lindstrøm]

Hi

On Sun, 2009-07-19 at 16:34 +0200, Marc Weber wrote:
> Hi Mad,

Mads, with an S, please :)

> 
> I'm glad you finally had the time to look into nix(os)!
> 
> You're welcome!

Thank you very much.

> 
> The nix language is able to express what you're looking for.
> Nobody has done so by now.
> Evaluation time will increase though.

Yes, and it be by so much that it makes my hole scheme non-practical. 

> 
> Andres (kosmikus on irc) made a student (J-roen) work on haskell packages..
> And I think he has something like this in mind as well.
> For haskell packgaes it actually makes sense because configuring with
> flags is scomplex but still doable in nix language.
> 
> What you tell is true. And it actually happened the last time
> stdenv-updates was merged in. sudo update broke a script launching qemu.
> It took me one week to track it down. But I had the choice and could
> choose when to upgrade!
> 
> Maybe think about it differently: One of the main strength of nix(os) is
> that if an upgrade fails you can switch back easily. So you may upgrade
> safely knowing that you don't have to work at night cause if it fails
> you can switch back. This kind of safety is one reason for me using
> nix(os). Another issue I was faced with was the update of gcc. gcc and
> those -O2 optimization settings made php behave strange catching
> exceptions. Using -O0 fixed it.

And this part of Nix rocks.

> 
> So we are at the point: How does this description of dependencies look
> like?
> 
>  gcc = version X  then use -O2
>  gcc = version Y then don't use -O2,-O1,-O3 ..
> 
> ....
> And you already see that it's a very much work to figure this out and
> test it. I don't even think we have the resources to do so.

I imagined that this should be automated somehow. See reply to Peter.
And people should be able to donated unused computer cycles.

> 
> But: If a package breaks for one of teh reasons you mentioned nix(os) is
> the only distribution I know letting you do a git bisect to find the
> "change" causing the failure easily. Of course this takes time. But
> using debian or gentoo I don't even know where to start because
> everything you have is emerge sync (which rsyncs all the package
> descriptions).. Of course you can put this into git yourself but you
> can't rollback easily if you broke the system.
> 
> Let's have a short look at systems which do what mentioned:
> python: setup-tools (easy-install), eggs:
>   quote: It's considered a bug if you require administrative priviledges
> php: pear
> ruby: rubyforge, ruby-gems
> Eclipse and its plugin system (which provides its own rollback facility)
> haskell + hackage..

Every programming community, creating their own solution. I much better
like Nix - that is, create a solution that works for 95% of the
developer population. And regular users too.

> 
> And indeed they cause some headache to me because I'm not sure whether
> I should package those stuff or just use it using easy-install and pear
> update etc..
> 
> I worked on ruby recently. I solved it by adding a gem nix command which
> creates a set of nix expression from those dynamic dependencies.
> The result is that you can just do nix-env -iA sup and it works.
> You can't do so on debian, can you?

No way, I can do that with Debian. Get me right here, from what I have
read, Nix is a huge step forward compared to Debian. And I do love
Debian.

> 
> So you could say nix is good at taking snapshots of software configurations
> which play together nicely.
> 
> Dependency and upgrade hell can't be solved in general but:
> using nix I know that when doing nix-collect-garbage everything is gone
> I no longer need.
> 
> Eg the plone buildout system doesn't remove old cruft AFAIK.
> 
> And yes: You have found one bad point about nix: If you upgrade X an old
> tool does no longer work. Actually this is an issue if you use special
> kernels. Eg ghc can't be compiled easily because binaries don't work as
> expected etc.
> 
> Nix even adds a new source of problem: You can't force users to upgrade
> their packages (thus fixing security issues).

I do not get this problem. Can you force Debian users to upgrade? It
seems to be the exact same issue with any other distribution.

And I do not see as I problem either. My distribution telling me that it
is very good idea to upgrade some package - fine. My distribution
telling me that I am stupid if I do not upgrade - maybe OK. Forcing me
to upgrade - hell no.

> 
> Anyway: the benefits are more important to me.. Even if you don't
> upgrade for two years you can still do so by using nix-install-package
> which installs the new required tools from urls. I don't think you can
> do this using debian or gentoo.

Yes, Nix rocks in this respect. I just thought it alleviated a problem
it did not alleviated.

> 
> Let me show you another nice point about nix: It's easy to install
> source (and generate tags automatically) along with libraries.
> Do you know any other system allowing you doing so ? [1]
> 
> Anyway you've heard that nix can let you experiment with these ideas while
> keeping the system running. That's most important to me.
> 
> Marc Weber


Regards,

Mads Lindstrøm


> 
> [1]
> 
> for haskell it looks like this (this install most packages which are availible at the moment)
> The last map adds the source derivation which also contains the tag files..
> 
> put this into your config.nix:
> 
>     haskellCollection = 
>      let hp = haskellPackages;
>          install = 
>         [ 
>           hp.alex hp.cabalInstall /*hp.ehc*/ hp.frown /* hp.haddock09
>           hp.haddock210 hp.haddock */ /*hp.happy117 hp.happy*/ hp.Agda /* hp.benchpress */ hp.binary
>           hp.cgi hp.convertible hp.cpphs hp.Crypto hp.dataenc hp.digest hp.dotgen
>           hp.editline hp.emgm hp.extensibleExceptions hp.fgl hp.ghcPaths hp.GLUT
>           hp.gtk2hs hp.haskeline hp.haskellPlatform hp.haskellSrcExts hp.haskellSrc
>           hp.haskellSrcMeta hp.HaXml /*hp.haxr hp.haxr_th */ hp.HDBC /* hp.HDBCPostgresql */
>           hp.HDBCSqlite hp.Hipmunk hp.hscolour hp.html hp.HTTP hp.HUnit hp.ivor hp.json
>           hp.leksah /*hp.maybench*/ hp.monadlab hp.MonadRandom hp.mtl hp.multirec hp.network
>           /*hp.nonNegative*/ hp.numericPrelude hp.OpenAL hp.OpenGL hp.pandoc hp.parallel
>           hp.parsec hp.pcreLight hp.QuickCheck hp.QuickCheck2 hp.readline hp.regexBase
>           hp.regexCompat hp.regexPosix hp.SDL hp.SDLImage hp.SDLMixer hp.SDLTtf
>           hp.Shellac hp.ShellacHaskeline hp.ShellacReadline hp.stm hp.storableComplex
>           hp.strictConcurrency hp.terminfo hp.testpack hp.time hp.time113 hp.uniplate
>           hp.utf8String hp.utilityHt hp.uuParsingLib hp.uulib hp.vacuumCairo hp.vacuum
>           hp.vty /*hp.wx hp.wxcore*/ hp.X11 hp.xhtml hp.zipArchive hp.zipper hp.zlib
>           /* hp.helium */ /*hp.hlint*/ hp.idris hp.lhs2tex hp.MazesOfMonad hp.uuagc hp.xmobar
>           hp.xmonad hp.xmonadContrib
> 
>           hp.hslogger hp.tar hp.bytestring hp.networkBytestring hp.syb
>           hp.ghcSyb hp.getOptions hp.multiset hp.filepath
>           hp.hsloggerTemplate
>         ];
>       in
>       misc.collection {
>         name = "haskell";
>         list = [ hp.ghc ] ++ install ++ (map (x : sourceWithTagsDerivation (sourceWithTagsFromDerivation (addHasktagsTaggingInfo x) ))
>                             (lib.filter (x : builtins.hasAttr "src" x) install
>                             ++ [ (hp.ghcReal // { srcDir = "libraries"; }) ] ) );
>       };
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20090719/1701acf6/attachment.bin