[lsb-discuss] LSB half walk between distro and not distro.

Peter Dolding oiaohm at gmail.com
Fri Mar 14 07:11:56 PDT 2008

On Fri, Mar 14, 2008 at 12:03 AM, Wichmann, Mats D
<mats.d.wichmann at intel.com> wrote:
> Peter Dolding wrote:
>  > Currently LSB covered libs are far to limited for a lot of
>  > applications.   Yet not all lib's are going to be needed by all
>  > applications.
>  >
>  > I do support for the www.winehq.org project.  It would be a great
>  > break threw if the project could stop making packages for every distro
>  > out there.
>  Hi Peter - thanks for chiming in!  We had some talks several years
>  back (with Dan) about Wine and LSB, and it eventually became clear
>  it was too early then.
>  One venue could be the Desktop Architects
>  Meeting which will be part of Linux Foundation's Collaboration
>  Summit next month.  I admit I haven't paid that much attention,
>  do you know if Wine folks are plugged in to that this year?
>  If I'm not wrong there have been people involved with Wine
>  at DAM in past years.

I do support in the main IRC channel I have not asked about that and
don't have cash to attend myself.
>  I don't know about this "end of Distros as we know it" :-) -
>  let's not be too incendiary, shall we?   I think it would
>  take a lot for distros to stop packaging so much, I would
>  always think the issue of trust would come out ("how could we
>  trust all of these packages coming from some source we have
>  no control over - guess who gets the support call?").

Sorry to say here with Wine winehq.org bugzilla and irc channel
basically gets hit by all dead packages and third party interfaces
that don't work any more.  So bad in fact at times wine supports have
to build replacement packages for distributions because the
distribution produced one is a lemon.  Worst case was over 200
bugzilla entries to clean up.   Wine support personal would love a way
to ban particular scripts we know that don't work any more being used
with more modern versions of wine.  Its a common argument distribution
must trust what they package.  Sorry to say when a distribution
package screws up the location they got the source from normally cops
the flame first for major applications.   Wine is not alone for this
apache, openoffice, firefox and the list goes on.

Its just like Windows applications if it don't work maker the
application is to blame.  Sorry to say its the way lots of users
think.  Does that the distribution built the package wrong cross there
mind no.   How much bad press do open source projects get because of
distribution stuff ups.  It has to be lots.  Basically the change of
distros as we know them is required to come into alignment with how
people treat Open Source Projects.

Asked how to proceed.  Biggest issue from Distros and People building
packages is the different security systems of Linux.  Now why should
they take third party packages if it will reduce there Distribution
security.  This really does need a full time focus group with the
single goal of making package and application security neutral to
Distribution and Security System.  This should cover profile system
control of what part of applications users can use.  This is basically
a complex project that for sure is going to steep on toes.  There are
a lot of big egos in the Security world.

RPM was picked because most distributions were using it.  Not on what
people need.  Really the RPM section of the standard really need to be
put under a major question mark.  Instead a list of features needed to
cover everyone feature requirements needs to be made.  The packaging
format open to what format can get closest to covering everyone needs.

Starting list of feature for the final format.
* Support for different distribution package names for needed
libraries .  So parts outside standard in older distributions could be
* Application binary correction of dependent libs in case of
distribution using different name for the same lib.  These corrections
could be master listed.  Faster move to a overall usable standard.  No
need to alter distributions move applications into alignment.
* Configure on Install without risking system security.  Only
application marked configuration files altered would a apply for most
* Clear support for in case of failure contact X party.  This could be
used by Distributions to send
* Options for integration into system wide configuration.   Windows
provides control panel still messy.
* Distribution dependent files to install.  This is a work around to
current day security models on Linux.
* Clean single file shipping system for all needed depends and optional depends
* Means to cleanly choose on install if optional parts should be
installs or not.
* Signing with identification of source required or package cannot be
installed.  Most likely something PGP.
* Support for third party repositories not getting over lapped with
main distributions installed files.
* Core distribution having LSB applications must be able to black ban
known security flawed libraries or applications.   Giving user warning
use this file support of Distribution will end.
* Core Distribution having the power to black ban stuff sourced from a
particular repositories due to known defective action.
* Core Distributions limitations must not be over ridable by a LSB package.
* Core Distributions able to limit to only approved repositories.
* Suitable source package format for the tweakers out there that
builds installable package these will be marked as clearly different
to normal packages reason different signing required.
* Simple reporting to Core Distribution of any third party installed
parts including status when installed.  Ie if user was breaking rules
and is now complaining about broken distribution.

Of course RPM might be upgradeable to the goals.  Since RPM got
standard Redhat basically sat back and did nothing.  We need to change
to a little proactive in needed features to remain the standard
packaging format.  No completion no development basically.

Extra Core Distribution Must to conform to LSB standard give clear
messages why.  Like libdvdcss is illegal to use in the following
countries if installed we take no responsibility.   Or X library or
application of version x has a known secuirty flaw.  Or sourced
repository has known construction flaws in the following.  Open
messages why its being blocked not just because we can.

To get support for third party repositories working right.  If my
application need X version of a .so  Distro ships with older that
cause my application to fail. There needs to be a way to install it.
Now installing it main distro could break it.  LSB applications need a
different ld.so search pattern to the distribution.  Currently we use
opt with application names under it.   This needs a slight alteration
from /opt/application to /opt/repository then reconsider if under that
we have the application name under that.   This way number of
duplicate .so files can be reduced.  Other is dealing with
applications that need older versions effectively in a repository
zone.  User notices that X application plays up when X lib is updated.
 Other applications work file.  No need to return all applications to
that older lib only the ones that need it.   This could be splitting
the repository or some other method.  This method could also be used
for distributions to provide backwards compatibly in a common style.
Or even LSB to provide backward  compatibly when standards are marked

These alterations do end the current Distribution model.  Everything
from one place.  Does not stop Distributions from mirroring the
repositories.  Returns balance.  You are right if Distributions don't
have control over the stability and the security of there distribution
they will not do it.  As with Debian proved past any question of LSB
format lacks features distribution will reject it.  Same with closed
source package makers.  Distributions have to wake up and smell the
.run files.  If they don't provide some suitable system nothing stops
application makers remaining with the evil root running .run files
that could completely bring there Distribution to its knees.   It is
in there best interest to be on board to a final and neat solution.
Currently .run files in closed source applications are more popular
than .rpm or deb.  Reason distribution alterations to final elf can be
performed and you have no problem doing configure on install.  Working
repository system could see User treat .run files as the devils they

Peter Dolding

More information about the lsb-discuss mailing list