Lubomir Kundrak wrote:
> On Tue, 2007-10-30 at 08:11 +0100, Hans de Goede wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>>> On Friday, 26 October 2007 at 07:17, Thorsten Leemhuis wrote:
>>>> On 25.10.2007 19:57, RPM Fusion Wiki wrote:
>>>>> The following page has been changed by ChristophKarl:
>>>>> Place your current requests here.
>>>>> + Request: Acrobat Reader
>>>>> + Summary: Viewing PDF Files.
>>>>> + URL:
>>>>> + Grounds for inclusion: For complicated documents Acrobat Reader
produces better results
>>>> As much as I would like a sane Adobe reader RPM in rpmfusion, it's
>>>> possible afaics. From
>>>> Note: Third-party websites must link directly to Adobe.com
>>>> download of Adobe Reader software. Hosting the software independently
>>>> not permitted.
>>>> IOW: we can ship that without breaking licenses, thus we won't ship
>>>> Same for flash-player afaik.
>>> We could provide nosrc.rpms like jpackage does, but we can think about it
>> Actually I have a group of students working on a third party application
>> installer for Fedora, which will use a combination of autodownloader, no src
>> rpms (which will automatically get build using "sources" downloaded
>> autodownloader) and system-install-packages, the end result will be a list of
>> applications like acroreader, googleearth, realplayer, etc. Which can then be
>> installed / updated with a single click by the enduser, while still getting
>> correct SELinux permissions, being easy removable as they will be installed as
>> rpms, etc.
> Are you creating a separate application, or integrating with existing
A seperate application using existing ones.
> Tried asking Panu if it would be a bad thing to make rpmbuild download
> files Sources tags if they are not available?
That wouldn't help, we want everything 100% gui based, gui based download
progress, gui based error reporting, etc. Hence we will be using autodownloader
for the downloads.
The idea is the user gets an "install third party applications" entry in his
application menu, and when started he gets a list of apps, with there current
status (installed & up to date, installed update available, not installed).
He can then click one to install / update.
Then he gets a dialog asking his permission to download, then a download
progress bar, etc. rpmbuild integration is not going to result in this kind of
end user experience.
It might, theoretically. I was talking about the yum plugin also.
Imagine having a repository of nosrc.rpm-s (and maybe src.rpm-s also)
and a yum plugin that would launch rpmbuild to build them. Either
rpmbuild or the plugin itself would download the sources, build the
package and install it. Then there is no need for a separate gui
application, user can choose to use pup/pirut or commandline yum -- if
he prefers -- to install and update such packages.
See -- you have the advantage of installing all the things with the
single tool. Probably it would be desirable just to create a category
such as "Untrusted third-party applications" in comps.xml.
I must admin I am not sure how to deal with user interaction if needed
-- permission from user to download blob and a huge warning that he's
downloading a stinky proprietary crap, and requiring him to accept a
kind of encumbering license, to be legally correct. As I've never
written a yum plugin I have no idea if yum deals with this, but I can
imagine it how it would be.
Lubomir Kundrak (Red Hat Security Response Team)