Re: [Fink-devel] How to make Fink more user friendly?
Le 15 juin 2012 à 17:53, Alexander Hansen a écrit : On 6/15/12 6:08 AM, Sébastien Maret wrote: Hi all, I spent most of this morning trying to install Fink on one of my colleague computer. This made me realize how complicated it is for the end-user. Pretty much everything that could get wrong actually got wrong: 1 - It took us a while to get the correct XCode version for 10.6 on Apple developer website 2 - When we finally got the correct version, it failed to install because of this bug: http://apple.stackexchange.com/questions/45841/xcode-4-2-snow-leopard-doesnt-install 3 - Once we finally got Xcode installed, we installed Fink and we had to fight with proxy settings to get through my institute firewall. The default selfupdate (through rsync) would not work, and we had to switch to selfupdate-cvs. 4 - We tried to build a software package (gildas) that depends on many others (gtk+2, gcc4.6) and this failed because of libraries in /usr/local 5 - Now with /usr/local out of the way the compilation goes on but it will probably take a few more hours. A regular user would probably had given up before having Fink working. Therefore I think need to think about ways to make this easier for the end user. We've been discussing for a long time about distributing pre-compiled packages; we use to have a binary distribution but it has not been updated since 10.5. I understand that it is a lot of work for a single person to build all the packages to make a binary distribution. Another option would be that each package maintainer builds the package he/she maintains, signs it, and upload it on a server somewhere (that's what Debian is doing, I think). How difficult would it be to have something similar for Fink ? Cheers, Sébastien 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. 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? 5) Yup. As for the binary distribution, there are several issues to address: I believe that signing packages might require a newer dpkg/apt. I've been testing updates, but (A) they still need some fixes to be fully functional, (B) the person who had been working on them (Sjors) isn't able to devote large chunks of time, and (C) I seem to be the _only_ one testing them and providing feedback. Additionally, we'd need a framework of some sort (like Debian's web of trust) to register all of the signatures for package contributors. It's very rare that a maintainer controls _all_ of the packages upon which their package depends, so we'd also need to have a policy about dependencies: e.g. if I update a package in the source distribution that has a versioned dependency on something you just updated there, and you go on holiday, then what do I need to do to be able to update _my_ package in the binary distribution? Do I sign for _your_ package and upload it? Do I have to wait for you to return? We could have the same policy than for .info files. If the maintainer is contacted and does not reply within xxx days, then other package maintainers (and/or fink-core) are allowed to upload .deb on the server. And there's the issue of the somewhere. In principle we could continue to use Sourceforge. Based on my experience with doing fink releases lately the file release system is actually reasonably fast currently--at least for files the size of the fink source tarball. How big is the full distribution in binary form ? Sébastien -- 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
Re: [Fink-devel] How to make Fink more user friendly?
On 6/18/2012 4:30 AM, Sébastien Maret wrote: Le 15 juin 2012 à 17:53, Alexander Hansen a écrit : And there's the issue of the somewhere. In principle we could continue to use Sourceforge. Based on my experience with doing fink releases lately the file release system is actually reasonably fast currently--at least for files the size of the fink source tarball. How big is the full distribution in binary form ? The debs from my latest 10.7 buildworld use up about 7GB of total space. Hanspeter -- 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
Re: [Fink-devel] How to make Fink more user friendly?
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
