[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:
> Another point to consider: the platforms on which we want to build a package in
> Hydra is not an inherent property of the package, but a part of the Hydra
> configuration.  (You might want to run your own Hydra instance and build some
> subset of Nixpkgs on different platforms...) So they should be specified in
> release.nix, not in the Nix expression for the package.

We may say that the package is supposed to work on some platforms (it
doesn't make sense to expect xscreensaver work on cygwin). We may build
some packages on all their supported platforms that are also supported
by hydra. One may want or may not want to apply this logic to all
packages with maintainer and platform specified..

We may have a list of packages, but require maintainer to be set and
then auto-remove "not-supposed-to-work-anyway" platforms.

Do you think that te first approach will quickly lead to undue load for
Hydra? Do you think that the second option is overcomplicated? Do you
think that Hydra builds should be configure totally independently from
maintained status and supposed platforms?

I agreed that decentralizing some knowledge about the package and trying
to use it for Hydra auto-configuration was an interesting concept. If
you  declare the experiment (or the idea thereof) to be a failure I will
agree without any remorse.  Or you can offer some general requirements
for such a system...

>>> 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.
> This turns out not to be the case.  For instance, if a package has a dependency
> "foo" containing an attribute "bar", it might evaluate "foo.bar".  This will
> barf if foo is {}.

OK, platformPackage/condPackage/... is not needed now. tryEval is more
than enough.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKlZdwAAoJEE6tnN0aWvw3ZT0H/2wwzorWUwD0h6Ye+uNCWBCU
oR8uUx20O+rLgiZjxLmYdHxpkeo7z2mUccgLXCXus8ZYisCxmXsy5rduBgBAlN9l
0YkTd2EpWJbniOo6dfPO6ciQJzcG8jqUdjX3aaZqYnYQsLv45df9J45Hgb/k2b0X
QgeLhTbD5gLDjDrVtitRYk0PNboWe5Vrf55GkgStTok4iTBQWbfzqm+mb6aBsjC5
e2GVdlx897rWWZW6ixLxDYQEgYG1cbiFIjQAwLMV/pYcJvJ8bC2Cdm7PmCFrVWR6
TlWT292/zLiUqpaVRJayZQCOtg3lEUV4SpSnf/7Q4T4fSQl9/QApwAxI2gpvLt4=
=55/C
-----END PGP SIGNATURE-----