| Message ID | cover.1606131550.git.h.goebel@crazy-compilers.com |
|---|---|
| Headers | show |
| Series | Update sequoia to 0.20.0 - version 2 | expand |
Hartmut Goebel <h.goebel@crazy-compilers.com> writes: > Hi Chris, > > thanks for sending the results of the data service. > > I adjusted the lint-errors. > > Regarding the failing builds: I had added these manually before the new > importer (see 38408) as ready. So I added "#:skip-build #t" for all new > crates, like the ne importer does. Thanks Hartmut. I haven't been following the Rust packaging very well, but my interpretation of #:skip-build would be that's it's like #:tests? #f, so if it's present, ideally there should be a comment there with some information about why this package isn't being built. Also, I think there could be some conflicts with a few of the patches you sent, the addition of rust-base64-0.13 for example.
Hi Christopher, > Thanks Hartmut. I haven't been following the Rust packaging very well, > but my interpretation of #:skip-build would be that's it's like #:tests? > #f, so if it's present, ideally there should be a comment there with > some information about why this package isn't being built. For those rust packages (aka creates) which are "libraries" it does not make sense at all to build the packages, since rust has no means of sharing pre-compiled objectfiles. Each and every program using a library builds it from source. This is why the new importer sets "#:skip-build #t" for all crates except of the ones listed on the command line. I'm not the one who came up with this idea, but, after being skeptical first, I fully agree to this decision. The only reason for *not* setting "#:skip-build #t" for these packages would be to have the tests run. But here again rust performs badly - adding a lot of overhead: Each package would be build *twice*: once for "release" (which then will just be dropped) and once for "test". And this will be repeated for every package on every system if substitutes are not available. > Also, I think there could be some conflicts with a few of the patches > you sent, the addition of rust-base64-0.13 for example. Sorry, I don't understand this remark. Why should adding a package cause any conflict?
Hartmut Goebel <h.goebel@crazy-compilers.com> writes: >> Also, I think there could be some conflicts with a few of the patches >> you sent, the addition of rust-base64-0.13 for example. > > Sorry, I don't understand this remark. Why should adding a package > cause any conflict? It won't. However, if two commits change the same place in a file, Git can't always work out what to do. For example, two packages get added in roughly the same spot. The conflict I'm referecning for rust-base64-0.13 is because rust-base58-0.1 has now been added in the same place (above rust-base64-0.12) [1]. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e94e86c92eddad0abfde00470c0269b4ddb0946e It's just unluckiy that this happened right after you sent your patches.
Hi Christopher, Am 28.11.20 um 14:26 schrieb Christopher Baines: > It won't. However, if two commits change the same place in a file, Git > can't always work out what to do. For example, two packages get added in > roughly the same spot. I still don't get your point. Merge conflicts are business as usual and I will of course handle them when applying the patches. Do you want me to send a new patch-set?
Hartmut Goebel <h.goebel@crazy-compilers.com> writes: > Hi Christopher, > > Am 28.11.20 um 14:26 schrieb Christopher Baines: >> It won't. However, if two commits change the same place in a file, Git >> can't always work out what to do. For example, two packages get added in >> roughly the same spot. > > I still don't get your point. Merge conflicts are business as usual > and I will of course handle them when applying the patches. My point was nothing more than there will be merge conflicts when merging these patches. I was looking at the data in the patch testing setup I'm working on, which had some trouble processing the patches: https://patchwork.cbaines.net/project/guix-patches/list/?series=5851 > Do you want me to send a new patch-set? Only if you want to, I think there OK as it stands. The only other thing I noticed when looking through them is that the indentation is off, judging by the number of changes when running ./etc/indent-code.el gnu/packages/crates-io.sqcm this isn't something limited to these patches, although it would be nice to fix the indentation for these changes before merging. Chris
Pushed as 6f9edf40b83782d81f4c1c91d97aa11d042506e0 Thanks for the review.