[lsb-discuss] PROPOSAL: requiring applications to be provided in RPM packaging format
fray at mvista.com
Mon Sep 22 12:53:12 PDT 2003
I think the theory behind the requirement is good. However, the
realities are that a lot of ISV software doesn't fit that mold very well.
Specifically MontaVista (whom I work for) has a single product that can
be installed as an OS (hopefully LSB compliant) or as an ISV product on
an existing OS (again, eventually LSB compliant). The problem is due to
the shear size of things.. (over 500 individual RPM packages.) We need
to have a specialized installation program, due to legal requirements a
click-wrap license, and other "traditional installer" things.
So while we meet the letter of the law "applications must be provided in
the RPM packaging format", we don't install our apps into the host's rpm
database, we don't want users directly accessing our rpm packages, etc.
While we're somewhat specialized in this, I do believe a lot of other
ISV will have similar issues. Especially when you are talking about
click-wrap licenses, and "pretty" installers. All of which definatly do
not fit the standard RPM mechanism.
So I believe it is incredibly important that the installed binaries meet
the requirements of the LSB for applications. It may be equally
important that at the least the install "location" is added to the
system RPM database (we don't do that today)... however, the contents of
the install location should be up to the ISV, while of course following
the LSB guidelines for binaries and general installation location.
Hopefully this makes sense... (The other thing to keep in mind is what
happens if someone wants to install multiple versions of the same
application... of course in different locations using RPM's relocation
functionality... this is the primary reason we do not populate the host
system's RPM database with our files.)
George Kraft wrote:
> The LSB v1.9 currently says that "applications must be provided in the
> RPM packaging format as defined in this specification."
> Ideally we wish there were a newer better install for Linux; however, for
> now many struggle with the LSB's RPM packaging format requirement. We had
> talked about allowing cpio and tar, but there are difficulties meeting the
> "requires lsb" requirement. Also, we are running out of time to make
> significant changes to LSB v2.0.
> Instead of compromising on our specification, perhaps we can be inventive
> with the FSG product standards. I propose we leave the LSB "as is" for now,
> but entertain the idea of "Requires LSB Runtime Environment". This would
> allow any kind of install mechanism as long as is "requires lsb".
More information about the lsb-discuss