søn, 22.05.2005 kl. 16.27 skrev Mike Hearn:
> On Fri, 20 May 2005 17:48:58 -0400, Paul Nasrat wrote:
> > It's merely set back. I'll send an update out next week
>
> Pup is this new "non threatening" yum front-end, right? Could we see
> screenshots of its current state at least?
>
> At the moment I'm not really convinced you can make a non-threatening yet
> useful frontend over a system like apt or yum ... short of asking people
> to embed Fedora specific information straight into web pages (which would
> suck massively) you can't get away from the huge list UI. Even if it's
> restricted to applications like what Ubuntu are doing, you still end up
> trying to give users the Ultimate Applications Menu.
>
> What I'm saying is, I'd really like to get more details on the UI thinking
> behind pup.
>
> thanks -mike
While we are talking about the subject, just got a somewhat crazy idea
for (3.party) package deployment:
Lets say Adobe wanted to make a really, really simple-to-use installer
for their reader. (the example could be used with any other 3.party
software, F/OSS as well as non-F/OSS, but i'll use adobe in this
example). Instead of presenting the user with a massive download page
"pick your distro (version), platform, etc." - they gave you a file
called AdobeReader.install. The user downloaded this file, and
double-click'ed it.
This would lauch some helper app, which would intepret the script -
within a standard interface - every installer would be more or less the
same. Some examples of "stages":
1. Welcome, a brief description of what the program does etc.
2. License agreement
3. which parts should be installed? (probably with one or more sets of
standards)
4. some nice progress bars while installing
(5. autoupdate on/off?)
(6. settings)
The install/autoupdate part should be integrated with yum - the
installer should put a .repo-file in /etc/yum.repos.d, and yum in the
neccesary parts from there - no need for the user to figure "wich rpm
does what" - and yum would also pull in the neccessary deps. autoupdate
would simply corespond to the "enablerepo" setting. Settings would
correspond to the config file (but should not be neccessary).
Ofcource, some scriptability (bash/perl perhaps?) would probably be
welcome. The .install files should also be able to hold "if-sentences"
for different arch'es/os'es (i.e.
"if (distro == fedora && version == 2 && arch=i386) {
use_repo("www.adobe.com/download/repo/adobereader_fedora2_i386.repo");
}
elseif (distro == suse && etc. - but it should probably not be using
c-style syntax :) )
In addition to "free download" software, this system should also handle
to be put on a cdrom (therefore - either handle paths relatively, or be
able to contain data such as rpm's within themselves). Some proprietary
vendors would probably also love if yum did make it possible to put
passwords on ftp's etc.
But this installation method could also be expoited further within
fedora itself. If we could create an on-line webpage where information
about different packages would be organized, a user could simply visit
this page, pick a package he/she would like to have, download the
.install file (say, abiword.install). There would (ofcource) *normally*
be no need to install - just check that the correct repo is there and
enabled.
This way, we could simply put a link in the menu, which opened "htmlview
http://packages.download.fedora.redhat.com"; - and have a nice webpage
there. No need for speciality, list-view-type apps. The webpage should
ofcource be localized (that is possible throug webagent strings, if i am
not mistaken).
Comments?
Kyrre Ness Sjøbæk
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
