[Nix-dev] Tracking upstream releases

[Ludovic Courtès]

Hi Nicolas,

Nicolas Pierron
<nicolas.b.pierron at gmail.com> writes:

> 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.

While I agree in principle, I think there's a number of issues that
would need to be solved.  Often, updating a package takes more than just
taking the new tarball:

  * At least you may need to fetch and check its digital signature or
    cryptographic hash.

  * Sometimes, new dependencies must be added, which you find out
    manually when trying to build it.

  * When the package has specific patches, they may have to be updated.

  * Last but not least, as Isaac suggested, you'd want to check the
    aftermath of upgrading the package---how many packages that depend
    on it are broken by the upgrade?

I think these constraints rule out a fully automated mechanism.

However, we could surely have tools to help us track upstream releases.
Debian has a tool ("watches").  For example, the `watch' file for
GCC 4.4 looks like this:

--8<---------------cut here---------------start------------->8---
version=2
ftp://gcc.gnu.org/pub/gcc/releases/gcc-(4\.4[\d\.]*)    debian  uupdate
--8<---------------cut here---------------end--------------->8---

(See
http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream
for details.)

I guess we could have a `meta' attribute to contain this kind of
information.  Then `nix-build' could be changed to actually use this
information; or there could be a dedicated tool.

What do you think?

Thanks,
Ludo'.