Hi Nicolas,
Nicolas Pierron
<nicolas.b.pier...@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'.
_______________________________________________
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
