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

[Tony White]

2009/7/22 Nicolas Pierron <nicolas.b.pierron at gmail.com>:
> 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.
>

Hi,
Yes! Sounds very nice and yep I bet the time spent bumping versions
that is saved would mean more time can be spent on patching or fixing
failed builds. The trade off would be worth it in the long run IMO.

I would be very much game for NixOs (And Nixpkgs) "Cooking on gas." :)

Thanks,
Tony