<davexunit>there's other, smaller issues that the 'git init' trick doesn't solve like auto-generated ChangeLog or perhaps more important files that need the actual git history.
<davexunit>in practice, a good number of gems on rubygems.org do have test suites and things
<davexunit>and the ones that don't are still source code releases
<davexunit>so my hope was that I could convince the rubygems maintainers to care about users being able to run tests on gems going forward, but they seem to only care about making the smallest possible gems that only include files needed at runtime.
<davexunit>I have pointed them at PyPI as an example to emulate, but they don't seem interested in learning from them, either.
<davexunit>cehteh: the ruby community is not very friendly.
<davexunit>and apparently no one sympathizes my desire for independent verification of gem tests in any sort of automated fashion.
<davexunit>they claim that gems are binaries (yet in practice they are source code) but have no concept of a source package.
<davexunit>and Bundler, the ubiquitous dependency management tool built on top of RubyGems, has a script that generates the boilerplate for new gems. that script creates a very important file, the gem specification file, that *shells out to git* to determine the list of files to include in releases.
<davexunit>I think we can all agree that coupling the build system to the version control system isn't great design, but nearly every single gem is inflicted with this.
<davexunit>the whole system appears broken, yet it feels like no one but me sees any problems.
<efraim>"Starting from this release, MPlayer no longer ships with an internal copy of libdvdnav and libdvdcss. You can use the libraries provided with your distribution, or compile and install them yourself. They will be autodetect at configuration time." time to fix the inputs and build again
<cehteh>davexunit: still understandable with the upstream attitude .. but about the argument that a .git is not deterministic, cant it be hacked somehow to consider it deterministic when the git branches/tags etc have the correct hash. from such a viewpoint git is deterministic and its storage internals are just implementation details
<cehteh>i think that would cover a lot other things as well and i like the idea not to roll release tarballs or whatever but give some git hash and done
<cehteh>(completely ignore .git, what matters is the checkout)
<davexunit>cehteh: but you can't import something downloaded from the net into the guix store without specifying it's hash
<davexunit>so, until git clones can be made deterministic, this will continue to be a problem.
<cehteh>i think that needs to be reconsiderd .. a git checkout is all what needs to be deterministic
<cehteh>when i discovered nix years ago i was rather thinking "why dont they build the store on top of git" :D
<cehteh>i mean there are always ways to shoot yourself into the foot .. if your build is not deterministic then it is not deterministic, having .git there or not might just be some way to generate some non determinism *if* you abuse is in some ill way
<cehteh>note that (IIRC) some time ago there where some probabilistic optimization strategies which led to non deterministic compilation in gcc .. dunno what happend to that if it got removed or disable
<cehteh>such would completely defeat guix/nix .. but still be some implementation detail
<davexunit>that's more than an implementation detail to us.
<mark_weaver>if we need the .git directory because the build system will be performing git operations, then it would entail taking on faith that the results of those operations somehow always end up the same
<cehteh>mark_weaver: not faith, your *checkout* aka source should have a determinstic hash .. and the binary generated then should be deterministic as well
<mark_weaver>cehteh: but ruby build systems run git commands as part of the build. that's why we need to keep the .git directory.
<cehteh>iff the build system does some magic git stuff which makes the build non deterministic then its not git's fault
<cehteh>even running git commands should be fine, as long it stays deterministic
<mark_weaver>so we'd have to be convinced that the differences in the contents of the .git directory cannot result in any change in the git operations.
<mark_weaver>for most of our packages that take sources from git repos, the contents of the .git directory are not used at all during the build, so we can simply remove it, and then there's nothing non-deterministic left.
<cehteh>yes .. but killing a .git is like killing a kitten :D
<cehteh>would be nice to have the .git stores externally and do checkout into your build dir
<mark_weaver>but if we need to keep the .git directory around, then that's a potential source of non-determinism, and who knows how it could be used for malicious purposes. if we don't verify it, we are opening ourselves up to someone exploiting security holes in git, for example.
<mark_weaver>not to mention that git uses SHA-1 as the hash, and SHA-1's security is not very good anymore.
<cehteh>you need to trust git that it cant be used that way true
<mark_weaver>davexunit: I don't understand why "git init" as an early build phase is so bad.
<mark_weaver>is there a practical problem with that approach? or maybe it doesn't solve all of the problems?
<cehteh>anyway .. keeping a .git could save a lot bandwidth instead cloning again, you may consider to have some mutable .git store somewhere and do the checkouts elsewhere so that no .git taints them but it stays somewhere safe