[Nix-dev] Re: Hey, this looks interesting

[Nicolas Pierron]

Hi,

Indeed, this is a great idea.

Many software are included in Nixpkgs and will become outdated after
an (mostly) undertermined period.  We cannot follow software updates
because we are just a few people maintaining Nixpkgs.  So if we want
to keep our softwares updated, we have to do it automatically.

Many commits until now have been made to to bump the version number.
This auto-update task can be seen as the patch-shebang function, some
things have to be done automatically because we don't want to lose
time on them.  We should focus our work on more valuable (without
expiration) features.  Thus, a tool which generates & maintains Nix
expressions could be extremely valuable.

We can imagine to have a tool which is called on special
meta-attribute to patch the "src" attribute of the derivation.  This
tool can generate a patch which is committed to the repository.  Due
to security issues we should keep these update out of the trunk.


One possible method (for an experimental branch):
----
The tool will download new releases and for each release it will copy
the previous versions and add it inside the
pkgs/.../packages/-version-.nix file (so every package will use ""
useVersion majorVersion "" or "" useVersion "default" "").  The tool
will check the compilation and mark it (with a comment) as failing or
compiling.  The generated Nix expression will be committed.

If the package compile, the tool will make it the default version and
check if all other softwares are also working as they were before the
change made in pkgs/.../packages/version-switch.nix then the change is
committed.
----

Unfortunately, such automated method may lead to a lot of issues.
Most of them should be checked and validate before the merging into
more secure branches are made.


On Wed, Jul 22, 2009 at 17:40, Tony White<tonywhite100 at googlemail.com> wrote:
>>>> http://oswatershed.org/
>
> Hi,
> Yeah, the tracking of distributions for freshness is a not the
> strength of the site IMO, it's the grouped tracking of upstream
> releases and how that information can be manipulated automatically.
> There would of course be the question of how reliable the oswatershed
> data is and whether it tracks every project.
>
> OpenSuSe should always come out on top if oswatershed tracks it's
> factory distribution, which I believe their developers already have
> some method to track upstream automatically but their developers don't
> actually push the version to the repo until the build succeeds and
> possibly some tests are passed.
> Because the oswatershed developer has done lots of the ground work, it
> seems silly to re-invent something that's already there and maybe can
> be used.
> If I knew any python, I'd dig right in. ;)
> Hydra could beat OpenSuSe factory by just trying to build everything
> as it usually does using the updated releases information from
> oswatershed to build fresh releases once a day.
> Failed builds may increase in the short term but it might result in a
> different workload for expression maintainers in the long run. Maybe
> even possibly leaving more time for good work in a good few instances.
>
> Download, sha256sum/md5sum, update expression, test build to fail,
> then patch or fix expression would become visit hydra and see what's
> broken, examine the log, grab the source, fix and update the
> expression. I guess.
>
> Of course, my personal dream of having a set of nix expressions that
> pull upstream source straight from bleeding edge cvs, svn, git, etc
> and fall back to the last tested working release revision from the
> same cvs, svn, git, etc repo if the build fails, probably wouldn't
> work at all using oswatershed's data. But it is a wild idea and would
> involve hydra, something I haven't even setup yet here and yes it
> would introduce a minefield, I know.
> If I ever try that, it's a long way off.
>
> Manipulating released updates as soon as upstream make them and
> automatically is certainly interesting from a security update
> perspective.
> Great for enterprise Linux where you want the security updates but
> don't want to break anything. Compared to rpm, nix is perfect for
> that.
>
> All in all I can see that the site does have some kind of future but I
> think the developer has his hands full, he'll need to track the
> various branches of each distro (Stale, unstable, experimental, etc)
> And also deal with some of the trolls that misinterpret his intentions
> and see his site as one big competition by ignoring them.
>
> I don't think putting the NixOS stable branch release on oswatershed
> would look very good but a more up to date branch might.
>
> Thanks,
> Tony
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>



-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
Donald Knuth - I can't go to a restaurant because I keep looking at
the fonts on the menu.