Am 18.06.2012 um 10:30 schrieb Sébastien Maret: [...]
>>> >> >> 1) We don't control Apple's servers. >> >> 2) I haven't seen this one, but then I'm still using Xcode 3.2.6 on 10.6. >> >> 3) We don't control what ports people's network admins leave open. > > Of course. My point is that if we had pre-compiled binaries, users would not > need to install Xcode. Also they would need to worry wether rsync and/or cvs > goes through their firewall since apt-get uses http. Note that "selfupdate-git" would also be using http(s), so that would also help with the second part of the problem. Next, I'd like to say that having a binary install, and a binary distribution, would be *really* nice. Ideally not just for 10.7, but also for 10.6 and soon 10.8 However, my feeling is that this is simply out of question for us these days, unless somebody with a lot of spare time, dedication and ability pops up to take on this big project. It's not so much the building of many .deb files, but rather it's the many, many tedious manual steps one has to undertake to complete a full bindist. IMHO a bindist only makes sense if it is frequently updated, otherwise it simply lacks too far. Thus the only sane way to tackle this all is to automate much *much* more of this than we ever did. Ideally, there'd even be a build server (farm ;), which does continuous integration: A few minutes after a new .info file was last committed, a job is started which first validates the .info file, then builds it, then queues it up for distribution. If any failures occur, they are logged and maintainers are automatically notified. New binaries then can be released, either automatically, or perhaps after some admins have given their approval. That would IMHO take much better care of security issues (with the exception of potentially spoofed .info files, of course -- so we need to (a) trust our package maintainers and (b) trust upstreams, but there is no helping that either way). The alternative, of letting everybody build and submit .deb files, IMHO is a very dangerous and difficult road to go down. I am a trusting guy myself, but when it comes to shipping binaries compiled by a "random" 3rd party to potentially tens of thousands of users isn't something I'd recommend. Even if we sign everything at every step, there is still the matter of trust having to be established, and the problem of the "weakest link" ... just one person that gets tricked via social engineering into accepting a .deb file without really looking too closely, or submitting a .deb file under own name, or anything like that, and BAM we'd have big fiasco at our hands... Even if nobody thinks about sueing... Note that we'd also need to host all those files with a big pipe. We are talking about multiple terabytes of traffic every month here, based on past experience. Just for reference, Fink-0.9.0-Intel-Installer.dmg for 10.5 only, has been downloaded 4.585 times in the last 30 days. Times 14.4 MB, this makes for 62 GB traffic / month, for this single, outdated file alone. Granted, it probably gets downloaded a lot by mistake by users on newer systems, but still, I vividly remember the traffic stats back in the day, and it was that big. I am not sure if our mirrors would be up to it. Luckily, though, SF.net seems to have a much, much better file hosting service these days, so perhaps they could be used for this purpose. Dunno... this would be a problem for much later to solve, I guess ;). > >> 4) We _could_ have fink complain instantly if /usr/local (maybe even >> /opt/local) is detected and refuse to build until that (those) are moved >> out of the way rather than getting down to the end and saying "oops, >> you've got stuff we don't like". I'd be in favor of that--it wouldn't >> be too tricky to implement. > > That would be great. We could even have Fink move /usr/local before compling > stuff, and putting it back in place when done. Or perhaps it is too intrusive? Way to intrusive, I fear. For once, many people (e.g. me) will have 1-2 fink builds running independently at the same time, and might be compiling something else in yet another window, and in a fourth terminal be using some binaries from /usr/local. E.g. I am using a self-compiled version of "git" these days, as I am developing some patches for git. This binary lives in git. I'd be really freaked out if I couldn't use those while compiling something with fink. But perhaps there are other ways Fink could hide /usr/local. E.g. a chroot jail could do the trick. Setting those up properly is quite some work, but it *could* be quite rewarding to implement such a thing for Fink. Alas, who will do it? Cheers, Max ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
