On Wed, 9 Aug 2017 22:23:41 +0200 Francesco Riosa wrote: > 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. : > > > On Wed, 9 Aug 2017 11:07:04 +1000 > > "Sam Jorna (wraeth)" wrote: > > > > > > What then is the benefit? If what is installed is the same from > > > > package manager or binpkg. Also your redistributing another's > > > > package in binary format which may not be legally allowed. > > > > > > The difference is that how the package manager/ebuild installs the > > > package may be better suited to the environment than what upstream > > > expects (such as upstreams that install through a .run file) > > > > I fail to see how basically skipping src_install and maybe some > > prepare stuff that makes it better suited to an environment. > > Can you explain that further? > > > > These packages are just exploded tarballs. I fail to see the benefit > > to repacking those into another tarball to be exploded. At best > > skipping src_install and/or prepare, seems to be the only > > difference. > > > one such benefit is that the binhost is known and managed by someone > you trust, SRC_URI point to the wider and dangerous internet. Interesting argument, saying upstreams cannot be trusted. Nor Gentoo with its manifests and hashes of the files referenced in SRC_URI. Given that most will come from Gentoo mirrors not upstream servers. Ignoring that the binhost has to use these SRC_URI's just the same. It makes sense in very strange way. FYI binpkgs have no hash. If someone did something malicious within the binhost to the binpkgs. You have no way of knowing. Yes the same can happen with ebuilds and manifest. But easy to sync portage and see if a manifest has changed. Therefore relying on binhost as means of security is possible but odd, as it leaves things open to potentially larger issues. > So please leave this as a configurable choice. For some things configurable would make sense. For things like fetch restricted, it would not. Since it is not legal to mirror that stuff to begin with. It surely is not to re-package. -- William L. Thomson Jr.