https://bugzilla.rpmfusion.org/show_bug.cgi?id=2483
--- Comment #39 from Alec Leamas <leamas.a...@gmail.com> 2013-05-29 21:38:09 CEST --- Thanks for taking time to reply. That said I think you miss the point in my proposal, which basically reflects comment #5 and comment #14. Regarding the downloader, it's totally unacceptable. Just the fact that it stores data not managed by rpm under /usr/share is end of discussion for me. Regarding your rpm, it's basic assumption is that it's OK to download the payload in a %pre scriptlet. My point (as well as Kevin K, Torsten L and Nicholas) is that this takes too long time to be acceptable - somewhat more formally it doesn't meet the "sane" criteria in the GL. Besides this, you have to take all kind of measures to walk around the normal rpm functionality. Since I'm not the only one with this remark, you might have trouble finding someone approving this approach. Regarding my proposal, the idea is to find a common way to handle this kind of software which cannot be re-distributed, with or without EULA restrictions. Yes, it's basically just a way to distribute just the spec and support files. But given the legal, administrative (Fedora GL) and technical constraints this is the path to walk IMHO. The design is (hopefully) open to a GUI interface (which is so much work to do that it really should be general, open to more than msttcore fonts). And, in the end, I envision a system like lpbs to just install and update the spec container (lpbs-* packages in my case) transparently. User will be noticed, be able to click a "Build and install" button and then be done after a root password prompt. Good enough given the constraints IMHO. -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.