On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Courtès wrote: > Hi, > > Efraim Flashner skribis: > > > The big problems are the recursive dependencies, the partial > > dependencies and the versioning. There are some that are easy to figure > > out, serde always needs serde-derive, winapi always needs the > > winapi-[i686|x86_64] crates, rayon -> rayon-core, etc. > > Do you mean that the crate importer returns partial dependency info? > That alone would be OK, many importers return incomplete dependency > info, but we can fill that out when making the package. It returns incomplete information. The way our packaging works it says that it wants the latest version of a dependency, but often it's looking for a different version. > > > I suppose one way to work around some of the issues is to make it so > > that the crates "build" by copying the source to %out/share/guix-vendor > > or something. > > So the core issue is that there’s nothing like shared libraries, is that > correct? This, in turn, means that there’s nothing to actually build, > and thus a crate doesn’t really map to a package in the usual sense of > the word, right? We can build it and run the tests, but it's not entirely useful. I have a blog post I'm working on, but basically if binary A wants B, and library B wants C, D, and E, A might only want B with features from D. So if B doesn't build because of C it doesn't prevent A from building. Plus logistically it doesn't really work to link libraries to binaries in the manner we're used to. > > In that case, what you suggest (copying the source in the package > output) sounds like it could work. It would be an improvement over what > we have now: the package graph would correspond to the crate graph. > It would also make it easier to patch the sources to remove vendored C libraries or patch Cargo.toml files. > Thanks, > Ludo’. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted