Feature changed by: Duncan Mac-Vicar Feature #305582, revision 3 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García Partner organization: openSUSE.org Description: - Idea from community member Raul Romero. + 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Stanislav Visnovsky Feature #305582, revision 5 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (2008-12-17 20:31:15) + Do you mean an ISO image containing an add-on product with privilege + separation? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Marcus Meissner Feature #305582, revision 7 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 :) + #4: Marcus Meissner (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) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Pavol Rusnak Feature #305582, revision 9 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 (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 (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 (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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Raúl García Feature #305582, revision 11 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 (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 (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 (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 (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 (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 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Pavol Rusnak Feature #305582, revision 13 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 ... -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Benjamin Weber 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 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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

Feature changed by: Duncan Mac-Vicar Feature #305582, revision 17 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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. #13: John Thomas (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( + #14: Duncan Mac-Vicar (2008-12-18 20:52:19) + (reply to #13) + Yes. Benjamin is right. + We are looking into this concept. There is a thread in zypp-devel about + this, and it is more complex than it sounds (requires the algorithm to + know where the package comes from and why it was installed, information + that is right now not available). + But please every offtopic conversation here will hurt the evaluation of + this feature later. Keep the discussion focused and based on research. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Federico Lucifredi Feature #305582, revision 19 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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. #13: John Thomas (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! + #16: Federico Lucifredi (2008-12-20 08:02:36) + the idea is interesting, but if it is really self-contained like an + MSI. With repos involved, I am not so sure... (referring to ml + discussion) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: robermann79 robermann79 (robermann79) Feature #305582, revision 21 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García (bgta) Interested: Andreas Jaeger (a_jaeger) Interested: Ján Kupec (jkupec) Interested: John Thomas (john_tomas) Interested: Michael Andres (mlandres) + Interested: robermann79 robermann79 (robermann79) Interested: Security Team (secteam) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Jakub Rusinek (liviopl) Feature #305582, revision 23 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García (bgta) Interested: Andreas Jaeger (a_jaeger) + Interested: Jakub Rusinek (liviopl) Interested: Ján Kupec (jkupec) Interested: John Thomas (john_tomas) Interested: Michael Andres (mlandres) Interested: robermann79 robermann79 (robermann79) Interested: Ruchir Brahmbhatt (ruchir) Interested: Security Team (secteam) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Sebastian Rösgen (palimpseste) Feature #305582, revision 25 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: New Priority Requester: Important Requested by: Raúl García (bgta) Interested: Andreas Jaeger (a_jaeger) Interested: Bernhard Friedreich (bernhard1234) Interested: Jakub Rusinek (liviopl) Interested: Ján Kupec (jkupec) Interested: John Thomas (john_tomas) Interested: Michael Andres (mlandres) Interested: robermann79 robermann79 (robermann79) Interested: Ruchir Brahmbhatt (ruchir) + Interested: Sebastian Rösgen (palimpseste) Interested: Security Team (secteam) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305582

Feature changed by: Michael Löffler (michl19) Feature #305582, revision 40 Title: Off-Line one click install (MSI for Linux) - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Raúl García (bgta) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: andrea florio (anubisg1) Feature #305582, revision 45 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:37:58 reject reason: Rejecting as per comment #17 from Federico: Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Raúl García (bgta) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one + #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) + because it's supposed to work offline.. what about if i miss any + dependency? i can't retrieve that online (since i'm working offline) + and actually i think you can't really provide a 4/5 GB OSI file. + i think that should "reduced" excluding all rpms provided by the DVD.. + in other words + if package X depends on Y available into the installation DVD --> Y is + NOT into OSI +   + if package X depends on Y NOT available into the installation DVD --> Y + IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, + you are supposed to be OFF line -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: 嘉樺 張 (iamchiahua) Feature #305582, revision 47 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:37:58 reject reason: Rejecting as per comment #17 from Federico: Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Raúl García (bgta) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI   if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. + #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) + PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: Michael Löffler (michl19) Feature #305582, revision 50 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:37:58 reject reason: Rejecting as per comment #17 from Federico: Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Raúl García (bgta) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI -   if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) #21: Todd R (theblackcat) (2009-12-03 16:55:51) Wouldn't this basically just be a package with an rpm file and a repo file?  You click the compressed file and it installs the repo and rpm (or vice versus).  You can already install a package with one click by downloading an rpm, and I think you should at least in theory be able to install a repository with one click using a .repo file, so combining these into a single compressed file should work more or less, right? -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: nick skeen (ns89) Feature #305582, revision 53 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:37:58 reject reason: Rejecting as per comment #17 from Federico: Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Priority Requester: Important openSUSE-11.3: Rejected by (flucifredi) reject date: 2010-02-21 20:33:06 reject reason: Not in this cycle. Priority Requester: Important Requested by: Raúl García (bgta) 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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) #21: Todd R (theblackcat) (2009-12-03 16:55:51) Wouldn't this basically just be a package with an rpm file and a repo file?  You click the compressed file and it installs the repo and rpm (or vice versus).  You can already install a package with one click by downloading an rpm, and I think you should at least in theory be able to install a repository with one click using a .repo file, so combining these into a single compressed file should work more or less, right? #22: Federico Lucifredi (flucifredi) (2010-02-21 20:34:44) We will limit ourselves to zypper, PK Applets, Yast, one-click and Add- ons. More abstractions to manage software are undesirable for now, we have enough on our hands already. + #23: nick skeen (ns89) (2010-07-30 00:05:28) + Doesn't Makeself already do most of this? + http://megastep.org/makeself/ -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: Roman Priesol (randybb) Feature #305582, revision 56 Title: Off-Line one click install (MSI for Linux) openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:37:58 reject reason: Rejecting as per comment #17 from Federico: Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Priority Requester: Important openSUSE-11.3: Rejected by Federico Lucifredi (flucifredi) reject date: 2010-02-21 20:33:06 reject reason: Not in this cycle. Priority Requester: Important openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Raúl García (bgta) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (Novell) Engineering Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Technical Contact: Benjamin Weber (benjimanw) 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 + detailed description is here http://old-en.opensuse.org/OSI + (http://old-en.opensuse.org/OSI) There is already a prototype working. Example script: - http://dl.getdropbox.com/u/363315/MozillaFirefox.osi + http://dl.getdropbox.com/u/363315/MozillaFirefox.osi (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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) #21: Todd R (theblackcat) (2009-12-03 16:55:51) Wouldn't this basically just be a package with an rpm file and a repo file?  You click the compressed file and it installs the repo and rpm (or vice versus).  You can already install a package with one click by downloading an rpm, and I think you should at least in theory be able to install a repository with one click using a .repo file, so combining these into a single compressed file should work more or less, right? #22: Federico Lucifredi (flucifredi) (2010-02-21 20:34:44) We will limit ourselves to zypper, PK Applets, Yast, one-click and Add- ons. More abstractions to manage software are undesirable for now, we have enough on our hands already. #23: nick skeen (ns89) (2010-07-30 00:05:28) Doesn't Makeself already do most of this? http://megastep.org/makeself/ -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: Karl Cheng (qantas94heavy) Feature #305582, revision 59 Title: Off-Line one click install (MSI for Linux) - openSUSE Distribution: Done + openSUSE Distribution: New Priority Requester: Desirable Requested by: Raúl García (bgta) Product Manager: Federico Lucifredi (flucifredi) Project Manager: Christoph Thiel (cthiel1) Technical Contact: Benjamin Weber (benjimanw) 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://old-en.opensuse.org/OSI (http://old-en.opensuse.org/OSI) There is already a prototype working. Example script: http://dl.getdropbox.com/u/363315/MozillaFirefox.osi (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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) #21: Todd R (theblackcat) (2009-12-03 16:55:51) Wouldn't this basically just be a package with an rpm file and a repo file?  You click the compressed file and it installs the repo and rpm (or vice versus).  You can already install a package with one click by downloading an rpm, and I think you should at least in theory be able to install a repository with one click using a .repo file, so combining these into a single compressed file should work more or less, right? #22: Federico Lucifredi (flucifredi) (2010-02-21 20:34:44) We will limit ourselves to zypper, PK Applets, Yast, one-click and Add- ons. More abstractions to manage software are undesirable for now, we have enough on our hands already. #23: nick skeen (ns89) (2010-07-30 00:05:28) Doesn't Makeself already do most of this? http://megastep.org/makeself/ -- openSUSE Feature: https://features.opensuse.org/305582

Feature changed by: Andrew Wafaa (FunkyPenguin) Feature #305582, revision 62 Title: Off-Line one click install (MSI for Linux) - openSUSE Distribution: New + openSUSE Distribution: Done Priority Requester: Desirable Requested by: Raúl García (bgta) Product Manager: Federico Lucifredi (flucifredi) Project Manager: Christoph Thiel (cthiel1) Technical Contact: Benjamin Weber (benjimanw) 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://old-en.opensuse.org/OSI (http://old-en.opensuse.org/OSI) There is already a prototype working. Example script: http://dl.getdropbox.com/u/363315/MozillaFirefox.osi (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?) Relations: - Specification (url: http://en.opensuse.org/OSI) 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 (benjimanw) (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) (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 (bgta) (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 (benjimanw) (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 (msmeissn) (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) (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 (john_tomas) (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 (bgta) (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 (john_tomas) (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) (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 (john_tomas) (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 (benjimanw) (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. #13: John Thomas (john_tomas) (2008-12-18 20:32:03) (reply to #12) Like i said before... uninstall is far away... :'( #14: Duncan Mac-Vicar (dmacvicar) (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available). But please every offtopic conversation here will hurt the evaluation of this feature later. Keep the discussion focused and based on research. #15: John Thomas (john_tomas) (2008-12-19 18:28:45) (reply to #14) Yes, You're right Duncan... I'm sorry! I really get of ground speaking about "that" specific subject... ;) anyway, if the prototype is working and just a small pieces are missing, why not put those pieces together and release the feature??? This is something really cool!!! #16: Federico Lucifredi (flucifredi) (2008-12-20 08:02:36) the idea is interesting, but if it is really self-contained like an MSI. With repos involved, I am not so sure... (referring to ml discussion) #17: Federico Lucifredi (flucifredi) (2009-01-26 21:01:53) (reply to #16) Postponing from 11.2 while we work on dist-upgrade (one biug problem at a time, please). Will reject once Next-release added to fate, so I can add that target before closing the 11.2 one #18: andrea florio (anubisg1) (2009-10-19 13:27:13) (reply to #17) because it's supposed to work offline.. what about if i miss any dependency? i can't retrieve that online (since i'm working offline) and actually i think you can't really provide a 4/5 GB OSI file. i think that should "reduced" excluding all rpms provided by the DVD.. in other words if package X depends on Y available into the installation DVD --> Y is NOT into OSI if package X depends on Y NOT available into the installation DVD --> Y IS into OSI, even if Y is into OSS/NON-OSS repo. just because as i sed, you are supposed to be OFF line #19: 嘉樺 張 (iamchiahua) (2009-12-03 03:22:48) PC-BSD is another example. It supports two format(PBI,TGZ) for software manager. The pbi format provided Completely graphical extraction & installation process. Also provided "Remove Programs" system utility to easy removal. #20: 嘉樺 張 (iamchiahua) (2009-12-03 11:14:09) (reply to #19) PBI screenshot (http://www.pcbsd.org/images/pbiinstall.jpg) #21: Todd R (theblackcat) (2009-12-03 16:55:51) Wouldn't this basically just be a package with an rpm file and a repo file?  You click the compressed file and it installs the repo and rpm (or vice versus).  You can already install a package with one click by downloading an rpm, and I think you should at least in theory be able to install a repository with one click using a .repo file, so combining these into a single compressed file should work more or less, right? #22: Federico Lucifredi (flucifredi) (2010-02-21 20:34:44) We will limit ourselves to zypper, PK Applets, Yast, one-click and Add- ons. More abstractions to manage software are undesirable for now, we have enough on our hands already. #23: nick skeen (ns89) (2010-07-30 00:05:28) Doesn't Makeself already do most of this? http://megastep.org/makeself/ #24: Andrew Wafaa (funkypenguin) (2017-05-25 10:38:01) This now exists with Flatpak (http://flatpak.org/) , Snappy (https://www.ubuntu.com/desktop/snappy) and AppImage (http://appimage.org/) . Closing as resolved. -- openSUSE Feature: https://features.opensuse.org/305582