Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Posted Jan 26, 2011 9:52 UTC (Wed) by rahulsundaram (subscriber, #21946)In reply to: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration by xav
Parent article: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Let's look at one aspect of the problem with the current model: If Firefox 4 releases tomorrow and I am using Windows or Mac OS X, I can install it immediately and in Linux, one usually has to upgrade their entire distribution. In Linux, there is no fundamental differentiation between system packages and even leaf applications. This is a problem that one has to solve and the current methods are awfully weak. The system admin point of view is great for servers but desktops need a different solution.
Posted Jan 26, 2011 10:08 UTC (Wed)
by niner (subscriber, #26151)
[Link] (1 responses)
Makes staying up to date with for example Firefox trivial.
Posted Jan 26, 2011 10:36 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 26, 2011 11:41 UTC (Wed)
by nicooo (guest, #69134)
[Link] (1 responses)
Which model are you referring to? I'm using gentoo and this works fine. The nice thing about distributions is that there are different models.
Posted Jan 26, 2011 12:15 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 26, 2011 21:10 UTC (Wed)
by jthill (subscriber, #56558)
[Link]
I think it's plain this notion produces exactly the same sequence as what produces the Windows nightmare: anyone can construct a web page or email and put anything at all at the fetch URL. No.
Clicking on a web-page does fundamentally change the process. It's a little weird to newbies. It takes manually fiddling with system files, unless somebody's already made an update-sources.list protocol. imho that's just barely enough to stave off the Windows nightmare now.
Because installing third party software with apt means running root scripts directly from whatever's behind the flashy link, does it not?
I think a third-party install scheme that protects the system and the user has to be cooked up before considering this.
Say, for third-party-signed packages create a new user/group combo, that can be tied to an "origin" key that must also have signed the package-signing key. For unsigned packags just use "nobody" or "third-party" or something, they don't care enough they can go in the swamp.
Something to that effect, for sure:: you want to also protect these packages from each other.
Run the package scripts on the package's userid, with a special service to install links into the system hierarchy. Apps will also want some writable .config or .local or whatever it is now subdirectory, also prompt users to grant access. Put the app's per-user config one level down, .config/example/example-config, so metadata is inaccessible to the app.
Log a copy of the outside-/opt actions to syslog, and show them to the user in like a three line text box with a that's all indicator. Offer "here's what's installed on your system. I've logged it to syslog. Want a copy?" <Save install log> <Thanks, I'm good>.
The access restrictions will stop most if not all of the Windows uninstall nightmare. Say add a product key in addition to the package key, then tag the directories with the responsible key. .config/opt/foo/.PRODUCT_ID_fingerprint doesn't match any installed package's fingerprint? It's stale. Make the tag file owned by root, the product's group, 744 so the user and app can verify, another service to update contents from newly-installed packages from the same origin. That's easily subvertible by the user
That, or convert everyone to kerberos...
Posted Jan 27, 2011 0:17 UTC (Thu)
by garloff (subscriber, #319)
[Link] (3 responses)
You happen to not have spotted openSUSE Build Service yet.
The main limiting factor here is that once you build on newer shared
Posted Jan 27, 2011 0:23 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Jan 27, 2011 0:27 UTC (Thu)
by garloff (subscriber, #319)
[Link] (1 responses)
Posted Jan 27, 2011 1:57 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Upstream has enough work cut out for them just getting the base to work (and fix bugs), asking them to also track whatever a few hundred (eo even just a dozen "mainstream") distributions are up to is just over the top.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
one-click third-party software installs
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
> install it immediately and in Linux, one usually has to upgrade their
> entire distribution.
It's dead simple to build packages for various distributions that you can simply drop in to older distros.
infrastructure it becomes more tedious ... but the FFox4 example is one
where this works rather easily.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
upstream community itself.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration