[Nix-dev] Re: [Nix-commits] SVN commit: nix - 16844 - raskin - in nixpkgs/trunk/pkgs: applications/misc/gphoto2 top-level

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eelco Dolstra wrote:
> It's not a good idea to have "platformPackage" in all-packages.nix.  It's a
> property of a package, so it should be specified in the Nix expression of the
> package, not in the composition (all-packages.nix).  Adding this kind of
> information to all-packages.nix will just make it harder to get rid of (most of)
>  all-packages.nix in the future.

In general, I agree. I welcome any solution to the problem. I just do
not see any simple good solution, so I start with simple and a good one
will emerge in the discussion.

> Also, returning {} will cause unexpected behaviour if the package is used as ara 
> dependency of another package (the latter will get an unexpected {} argument,
> which may or may not cause evaluation to fail (I guess it does); "abort" or
> assertion failures on the other hand are always propagated).

It does, because package always wants a derivation to either be
convertible to path or contain an attribute with pre-known name. Both
assumptions will fail.

> Why not use a meta attribute for this?  Maybe stdenv.mkDerivation could be
> modified to look at the meta attribute and throw an abort error if the platform
> doesn't match.

For a trivial reason. I want hydra to evaluate meta (or some parts of
it) even though a package contains a failed assertion.
Maybe adding an operator to catch the presence of a failure (although
not the reason of the failure, of course) has some merit.

> In fact, I see that you added a meta.platforms attribute.  What is the intended
> semantics of that attribute?
> 
> - That the package is known to only work on the listed platforms? (E.g. packages
> in os-specific/linux.)

It is so for packages where I used platformPackage. Because they had
assertions initially anyway..

> - That the package is only supported on the listed platforms? (E.g. it might
> work on others, but we don't know and there are no guarantees.)
> - That the package should be built in Hydra on the listed platforms?

These too probably become closer with time..

Currently the formal meaning of meta.platforms is for Hydra to build the
program. I am fully willing to implement a better naming scheme. Maybe
supportedPlatforms / brokenPlatforms is a fine pair of attributes?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKk7wxAAoJEE6tnN0aWvw3PSMIAKlLi4k34dRM6DKoLlI9WUiU
VCRiwm58OEPJRg4w09p4p7o4JUB7amGyw/hNjY2GJfIRNDuHsNs4z4CdQl1rE7JK
GkEQP/nfTcLfm9+Dnomt2uyYEntB43sLX+fkbjsibItBliQxGCHlrYG9VHOPuK7u
Mns+H91S3imzFxGPegEfDoUQizMRo8P69Dgf4RUurw0DEA84C6C0t1CQrp7kgcgs
1Q+goemIR61Is1xwixZRYT9kyw/Ig2gFs8NUmbPSJGMsubQPhC2evmgF8T0VjAqw
tR59o1Nb1sK0KANdoRMjIFd/nPTaPSHkU7KrpqRcV4dz2CcJFCC+GwKfRSjtR6Q=
=3C8j
-----END PGP SIGNATURE-----