michael.leibowitz at intel.com
Sun Oct 22 17:19:39 PDT 2006
I'm intrigued by the idea of "re-registering" a package with a shared
interest (like plugins), but think it may be somewhat difficult in
practice. What happens when firefox is upgraded in the distro's
repository? The secondary package manager doesn't have a repository for
it, so it doesn't know how to update it. The user has a potential
vulnerable version of firefox installed. What if it were sendmail? It
would be problematic to have two sendmail's installed.
Software Engineer, Channel Platform Solutions Group
michael.leibowitz at intel.com
+1 503 264 7621
>From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
>bounces at lists.freestandards.org] On Behalf Of Alexey Eremenko
>Sent: Saturday, October 21, 2006 12:47 PM
>To: lsb-discuss at lists.freestandards.org
>Subject: Re: [lsb-discuss] Packaging
>hi all !
>before I begin lets learn two terms:
>-first package manager (=distro-specific-PM) (=base PM)
>-second package manager (=LSB-PM)
>I thought about package managers recently.
>I think that by converting packages (from second to first, like
>alien), it would be hard to achieve good stability.
>I came to conclusion that second package manager must exist, with only
>few mandatory packages installed already, those are:
>This way, all apps and plugins will be dependent on those 2 packages
>(which must always exists), so this way all normal GUI applications
>(like Photoshop) could be installed easily.
>Now with plugins it is a bit more complex.
>What if you want to install a plugin for FireFox ?
>I think that the second (read third-party) package manager must copy
>it from the first package manager (read the PM, that's included with
>i.e. Re-Register with LSB PM.
>This idea (unlike alien) will not mess the base PM, so at worst case
>your plugin will work after you install manually second copy of
>So with my approach the max risk is:
>Having 2 copies of FireFox installed side-by-side. (one from LSB PM,
>one from base PM)
>With alien approach the max risk is:
>ending up with messed package manager that refuses to work.
>WARNING: for Open-Minded people Only !
>Other things to think about:
>1. Do we need conventional Packages for third party apps ?
>I think something revolutionary such as "klik" is very good.
>i.e. we still need ability to register packages with desktop
>environment and resolve-dependencies of course, but I don't think that
>we absolutely must install packages as we do it with rpm/deb. I think
>just running them uninstalled (like klik) is good idea. (provided we
>can register them in our start menus)
>Bottom Line: We need some technology that has advantages of both klik
>for those new to the concept:
>Klik allows users to download-and-click on klik packages to run them
>instantly, without installing anything, which is very convenient.
>read more on: klik.atekon.de
>2. The second PM must be optimized for user-wide setups instead of
>While both rpm & deb allows to install for single user-only by doing
>tricks, this is non-standard procedure.... why is this ?
>In Home environments it is nice to let 2 users install each to his own
>account without messing the rest of the system. ...And make it easy to
>install is important too !
>lsb-discuss mailing list
>lsb-discuss at lists.freestandards.org
More information about the lsb-discuss