> 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ż <[email protected]> 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 <[email protected]>: > >> 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 >> [email protected] >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev >> > > > > -- > Tomasz Czyż > > _______________________________________________ > nix-dev mailing list > [email protected] > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list [email protected] https://mailman.science.uu.nl/mailman/listinfo/nix-dev
