Mailinglist Archive: opensuse-features (26 mails)

< Previous Next >
[openFate 305582] Off-Line one click install (MSI for Linux)
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 18 Dec 2008 19:21:03 +0100 (CET)
  • Message-id: <feature-305582-15@xxxxxxxxxxxxxx>
Feature changed by: Benjamin Weber <benji@xxxxxxxxxxxx>
Feature #305582, revision 15
Title: Off-Line one click install (MSI for Linux)

openSUSE-11.2: New
Priority
Requester: Important

Requested by: Raúl García <raul@xxxxxxxx>
Partner organization: openSUSE.org

Description:
Idea from community member Raúl García.
Same concept as MSI packages for Windows but exploiting the One Click
Install concept of openSUSE (and therefore inheriting the simplicity,
code and security.
Basically a compressed file which includes a repository inside, plus
one click install information, and a script to trigger the
oneclickinstall handler with the data as payload in the script.
Therefore is a collection of rpms that can be installed
detailed description is here http://en.opensuse.org/OSI
There is already a prototype working. Example script:
http://dl.getdropbox.com/u/363315/MozillaFirefox.osi
This requires some extra features in one click install and other pieces
* ability to force OneClick to add the repo (the one inside the
compressed file)
Additionally I see other features:
* ability to suggest an update repo for the installed bundle
* support from build service to generate bundles
* easy way to generate them locally
Out of scope but interesting:
* Ablity to trigger a YaST workflow (its own control.xml?)


Business case (Partner benefit):
openSUSE.org: This solves the business case of distributing service
packs, applications, codecs bundles by just downloading a big file,
100% offline, supporting dependencies and repo signatures.

Discussion:
#1: Benjamin Weber <benji@xxxxxxxxxxxx> (2008-12-17 18:38:57)
Sounds good. I suggest not using a shell script to start the process as
this could contain anything. Executing arbitrary untrusted code is not
really a good idea. An archive containing metadata coupled with a
handler that understands the format should be sufficient.

#2: Stanislav Visnovsky <visnov@xxxxxxxxxx> (2008-12-17 20:31:15)
Do you mean an ISO image containing an add-on product with privilege
separation?

#3: Raúl García <raul@xxxxxxxx> (2008-12-18 13:01:10)
The shell script will be executed by the user, with user privileges.
Once the file is decompressed, the "One Click Install" is launched and
it's works normally but with a local repository.
Yes, the shell script could be altered, but any shell script could be
altered :)

#5: Benjamin Weber <benji@xxxxxxxxxxxx> (2008-12-18 14:03:40) (reply to
#3)
"The shell script will be executed by the user, with user privileges... Yes,
the shell script could be altered, but any shell script could be
altered :)"
The point is not that the script could have been altered, but that the
user has not chosen to trust the vendor at the time of executing the
shell script, so should not be executing arbitrary code from that
vendor. Furthermore, when the script is executed there is not even any
way of knowing that the script is really from the vendor the user
thinks it is from, or has not been modified in transit.
It is safer to have just metadata in the archive, which is read by a
handler and any scripts are executed only once the user has chosen to
trust the vendor.

#4: Marcus Meissner <meissner@xxxxxxxxxx> (2008-12-18 13:07:13)
Security comments.
- There should be a signature / key already in tarball that validies
all other data - and why not a repomd tree, with everything reviewable
from repodata/repomd.xml
- what advantage brings this compared to just a tar-ed up RPM-MD tree
in usual format and signature checked?
(and btw, the example script on the page has /tmp problem en-masse)

#6: Pavol Rusnak <prusnak@xxxxxxxxxx> (2008-12-18 14:08:50)
I'm against executing any shell scripts. I think Marcus has the point
and it was exactly my thought.
OSI file should contain:
* tared (and compressed - probably lzma) repomd repository
* signature
* list of packages that are required/recommended/suggested to install
from this repo
We could reuse YMP-handler, which will only add compressed repository
to system, do the workflow and remove it right after installation.

#7: John Thomas <jonh_tomas@xxxxxxxxxxx> (2008-12-18 17:47:09)
How would it handle the remove of the same software a user have just
installed using this process???
will it be as simple as installing???

#8: Raúl García <raul@xxxxxxxx> (2008-12-18 17:59:13) (reply to #7)
One Click Install is expected to support the removal in the future with
the same .ymp

#9: John Thomas <jonh_tomas@xxxxxxxxxxx> (2008-12-18 18:05:54) (reply
to #8)
Well... that seems a very distant future!!!
shouldn't you wait for that feature to came out first??? i mean... Your
idea is really great but with no uninstall feature... well it will be
missing a very important part!!! (crucial i would say...)
I saw PC-BSD's PIB and it seems really interesting!!! It seems very
complete!!!

#10: Pavol Rusnak <prusnak@xxxxxxxxxx> (2008-12-18 18:09:35) (reply to
#9)
On the contrary: from my point of view adding removal feature is very
easy. UI will present the list of packages from the metadata, user will
do the selection and then these packages will be removed with zypp ...

#11: John Thomas <jonh_tomas@xxxxxxxxxxx> (2008-12-18 18:45:49) (reply
to #10)
But it would present all the dependencies or just the ones installed by
that specific action???
If it would just present the ones installed by that specific
installation then you mean that what is asked here
(http://opensuse.awardspace.com) is easy to implement...

+ #12: Benjamin Weber <benji@xxxxxxxxxxxx> (2008-12-18 19:21:11) (reply
+ to #11)
+ Getting a bit off topic but some of the reasons it's not trivial to
+ implement the uninstall is that you
+ a) need the history of what packages were installed as part of the
+ installation (including automatically selected dependencies)
+ b) Need to only remove the packages that were installed by the original
+ installation but are not required by anything else that was installed
+ subsequently (we don't want to uninstall unrelated things).
+ c) Need to cope with users removing individual packages manually since
+ installation. When do we decide that the application is no longer
+ installed?
+ ... and several others that I thought of but can't remember off the top
+ of my head. The biggest problem is a) As we do not have a transaction-
+ level history of what packages were stored afaik, and are certainly not
+ tieing it to application level metadata.



--
openSUSE Feature:
https://features.opensuse.org/?rm=feature_show&id=305582

< Previous Next >
List Navigation
This Thread