[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