baeder at cadence.com
Mon Oct 23 13:13:56 PDT 2006
> First of all, as should be obvious, the details of internal package
> dependencies for packages provided by the distribution go away.
As someone who has dealt with applications approaching the complexity of
the OS, I would TOTALLY agree...the LSB process should NOT be trying to
focus on the installation of packages, but of applications. I should
assume that the things that are LSB provided are external, but in some
sort of a well know place, and for EVERYTHING ELSE, I should supply it.
Yes, it can make things messy if I interact with sendmail or other MTA,
and change it's configuration. Maybe *I* will need to be re-configured
after an update to sendmail, or a change to the MTA...I don't think we
can ever be 100% "fool proof".
> Secondly, the last time we talked to ISV's, a significant number of
> them were **not** interested in a new package manager. The problem is
> that a many of the larger ISV's have already a huge amount of
> investment using either their own package installation system, or some
> commercial/third-party provided package installer (i.e.,
> InstallShield), and they want the "install experience" for the
> customer to be the same across all platforms --- Windows, Solaris,
> AIX, and Linux. And they can do that today using some of these
> commercially written package management systems that use Java, for
AMEN BROTHER - SAY IT AGAIN...
> So for those folks, what they need is an interface to the *existing*
> package management system to inform the package management system that
> package _foo_ has been installed, and that if package _foo_ needs to
> be uninstalled, to please run the deinstaller at a particular
> pathname, which will return either an exit status of 0 if the
> deinstallation was successful (and so the package name can be removed
> from the package namespace), or 1 (if the package deinstallation was
> cancelled or failed).
Or maybe NOT EVEN THIS...On Windows, I see more an more programs
providing an UN-Install "link/shortcut" in the menu listing for that
application. Do we really need a "global" namespace? What about all
the applications (like EDA, MCAD, etc.) where the typical scenario is to
"install" on a centralized file server. Then all I need is to set up
the right "paths" (for the shell and loader) to run the application.
Yes, there are still "dependencies" to worry about - i.e. is the right
version of a specific kernel or "patch" available - BUT hopefull, that
is something that LSB compliance would help remove as an issue (at least
I have seen that the dependency issue CAN BE a nightmare. We have it
between different product lines inside our own product portfolio. All
we can do is isolate them the best we can.
I see LSB's efforts here to be the same sort of thing. Find the things
that need to be COMMON, and make sure that they are common and
available. All the rest is something that each individual ISV needs to
worry about (and HIDE) from other applications.
Of course, as in the case of the sendmail "add-on" or other add-ons, the
interfacing between different applications (even if from the same ISV)
is the real issue. So, rather than worry about the packaging (and
delivery), maybe more work is necessary on the interfacing process...
Anyway, my $0.02
Scott Baeder Cadence Design Systems, Inc.
Senior Architect 270 Billerica Rd,
Chelmsford, MA 01824.
Tel (978) 262-6299 (MA) Fax (978) 262-6777 (MA)
(408) 944-7785 (SJ) Cell (508) 331-1530
More information about the lsb-discuss