>> 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/
/usr/bin
/usr/bin
/var/share/
/var/lib/
- help in admin files leveraging (portability) : init.d scripts, cron
scripts, ...
- help in libs dependencies (& symbols) : if ISV package depends on
libjpeg6. then we must provides ways in packaging system to assert
on this dep() : 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
--
.''. - our own. Resistance is futile.
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
