[Nix-dev] Re: Auto-updating sources: handling the general case

Yury G. Kudryashov urkud+nix at ya.ru
Fri Aug 20 00:29:57 CEST 2010


Michael Raskin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> What can be done:
> For general case there is update-upstream data. There are some fixes
> that can be made:
You should not assume that people know what is "update-upstream data".
> 1) We have "callPackage" now. That allows evaluating package (or some of
> its attributes) without guessing how it is called in all-packages.nix.
> 2) It looks like "nix-instantiate --eval-only --xml --strict" is stable
> now. So there is no need to build some temporary derivations for robust
> getting of attributes from attrsets.
> 3) The resulting source data (url etc.) can be put back right into Nix
> expression if we require marking the generated attribute set by putting
> something like ``autoGeneratedClause = "auto-update";''. The hard part
> (writing regexp for finding such attrSet in the expression text) is
> already done (in CL-PPCRE tree syntax - debugging this as a
> string-expressed regexp is too hard). Or maybe we want to fix
> "--parse-only --xml"? In that case we will need a lot of position
> information, though.
Hm... Didn't understood. Can we start by disscussing what should be in nix 
expressions, not how should we parse them?
> 4) The attributes should be designed from the beginning for different
> methods in different cases. I.e. there is a "method" where we read
> sourceforge page and find the latest release (optionally: filter by
> filename, process nested groups); there is a method where project
> news/download page contains a direct link to the latest version; etc.
We can have some attributes for the "general case" and functions that 
generate these attributes for specific cases.
> 5) Version extraction should also be split into different handling
> methods.
> 
> I guess the thing requiring most synchronization is naming.
Yes. I think that we should start by disscussing what metadata we want to 
store in the expression, then how should we store it.

I think that the following metadata should be extractable from nix 
expression:

1. How can one obtain the list of all available versions (an FTP directory, 
a page with download links etc.)?
  a) stable versions;
  b) snapshots;
  c) betas;
  d) development repository (+some well-known branch names?) <-- this could 
be integrated with repo-manager.

This "stability" information could be used to test pre-releases in branches.

Michael, could you please describe the attributes update-upstream-data uses? 
We can use these names as a starting point instead of reinventing the wheel.

2 (optional). Does upstream signs the releases? If yes, key id+fingerprint 
and URL of the pgp-signature.

P.S.: I don't think that package upgrades should be performed by computers. 
I think that each new version must be reviewed before commiting to svn.




More information about the nix-dev mailing list