[Nix-dev] Auto-generated expressions for applications

[Freddy Rietdijk]

> Current approach seems to be doing the job except notifying people when
dependency is updated.

What do you base that on? With the generated data sets for applications we
have another issue which I didn't mention, and that is the sometimes overly
conservative pinning of versions by the application developer. Aside from
reporting such issues upstream, how to handle that?

Other distributions face similar issues but, at least with Python, on a
smaller scale, because they cannot have multiple versions of packages and
therefore having separate package sets is just not an option for them.

Maybe I should have written in the initial mail that I'm looking for a
policy on how we're going to deal with these ki nd of situations.

On Tue, May 30, 2017 at 2:10 PM, Tomasz Czyż <tomasz.czyz at gmail.com> wrote:

> Current approach seems to be doing the job except notifying people when
> dependency is updated. Previously we had monitor to do some similar stuff,
> and I think vulnix can check that without much effort so I wouldn't worry
> about having duplicated packages for apps.
> I think focusing on improving CI process and security notifications
> process is the way to go.
>
> Probably we could set another process/job in hydra to check all apps for
> security issues/updates. (I'm not sure if security team doesn't have that
> already).
>
> 2017-05-30 10:17 GMT+01:00 Marc Weber <marco-oweber at gmx.de>:
>
>> Let met try to sum up what I remember:
>>
>> - There 3+ solutions to update "sources" documented on the wiki
>>   somewhere - ideas from comparing versions with other distributions up
>>   to adding scrapers getting latest version from web sites if I recall
>>   correctly
>>
>> - Putting automatically generated code into nixpkgs doesn't solve all
>>   issues, for corner cases you have to duplicate dependencies using
>>   different version constraints.
>>
>>   -> overhead
>>
>> - Its not always quite clear how stable the user wants to be
>>   (gimp/inskscape) case, master sometimes has new features.
>>
>>   So which versions to support ?
>>
>> - Whatever we do, we don't solve anything for other distros (which
>>   suffer the same problem), unless we switch point of view:
>>
>>   The solution would be a cross platform cross language dependency
>>   management system allowing to declare dependencies in a file so that
>>   you can even install from gihtub automatically.
>>
>>   systemPackages = [ (fromGithub "user/package" "HEAD") ] # sort rest out
>> on your own, thanks
>>
>> package A could be working, package B could be working, but [A B] in the
>> same environment not (because they both depend on executable C)
>>
>> After all we want nixpkgs to be at least stable enough to have broken
>> packages marked as broken and expect everything else to at least
>> compile/install.
>>
>> Which are the best short/middle/long term solutions ?
>>
>> Marc Weber
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170530/5a64955f/attachment-0001.html>