https://bugzilla.rpmfusion.org/show_bug.cgi?id=2483
--- Comment #39 from Alec Leamas <leamas.alec(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.