LSB Package API

[Michel Briand]

>> I think you are looking for a solution to a problem that doesn't exist.
>> For the corner cases of where this does apply (proprietary software)
>> this is not enough of a use case to justify all the work required.
>
>I don't think this is a corner case at all. For one thing, propietary
>applications might just don't play a role _because_ there is no really
>good distribution method for them - the typical chicken-and-egg problem.
>(I'm not saying this is the only reason, but an important one.) We're
>just not giving them an easy method of cross-distro integration. I think
>providing this is important.
>
>Second, this way of distribution will help open-source projects as well.
>It would make it really easy for them to distribute bleeding-edge
>versions of there apps that integrate well into the packaging system
>without having to package for each and every package manager. It will
>also help those projects which are not widely used enough to be in
>distro repos, as they can more easily release binary distributions
>without having to depend on getting packaged by the distros. I really
>believe this decentralism would be very nice to have, especially in
>something as naturally decentralized as the open source community.
>

Hi,

I'd agree with Richard, because helping ISV won't automatically help
Debian community to improve itself or its product : the Debian distro.

Helping ISV, in a way that can benefit to all is to provide a very
good, and solid-rock, basis for all to package software, respectful of
LSB and knowledgeable in UNIX :).

ISV may benefits from an improved packaging infrastructure but we would
not benefits from them : we do not care about them at all :). So we
want to care about invest time for those fishes...

Sure, I'd like to have a Debian package (updated monthly) for
IBM/Rational ClearCase (though I'd like to use Aegis...), for NVIDIA
Gelato or for Autodesk Maya....

But we don't want to invest time before they take effort in packaging
they stuff.... ;)

I'm used to comply with very heterogeneous environment as Linux + HP-UX
+ Solaris + Window$ ... that's crazy...

Common drawbacks in packaging approaches are, usually:

- poor asserts of target particularities,
- lack of UNIX knowledge,
- (very, very) bad scripting (all to often are very bad *csh* scripts
for example).

IMHO, to improve such things, to help design install scripts, or
install schema, in a way that can fit in UNIX / Debian philosophy, we
can produce documentation that:

- respect LSB hierarchy so that files goes where we want them to go,

	/etc/init.d
[debian]/etc/default/$PACKAGE
	/usr/bin
	/usr/bin
	/var/share/$PACKAGE
	/var/lib/$PACKAGE

- help in admin files leveraging (portability) : init.d scripts, cron
scripts, ...

- help in libs dependencies (& symbols) : if ISV package depends on
libjpeg6.$VER then we must provides ways in packaging system to assert
on this dep($VER) : with the new *dpkg-shlibdeps* we can tracks such
symbol dependencies...

- help document the new *dpkg* feature of "triggers", this might help...

- and last but not the least : KISS ; why use DBUS !!! when all Debian
packaging tools use either Bash either Perl ????? why complexify
things ? that's the root of all evil :))))))))

To conclude: the best way is to document, and eventually to implement
helper scripts. Not to imagine API that would become obsolete in a month
of two... Figure out where ISV script are not able to cope with Debian
system and offer solution for that problems, specifically :).


Best regards,
Michel
-- 

 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-    our own. Resistance is futile.