standard dependancy system
nicolas.mailhot at laposte.net
Tue Dec 11 07:53:26 PST 2007
Le Mar 11 décembre 2007 16:36, Patryk Zawadzki a écrit :
> 2007/12/11, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>> Le Mar 11 décembre 2007 15:12, Patryk Zawadzki a écrit :
>> > 2007/12/11, James Richard Tyrer <tyrerj at acm.org>:
>> >> Yes!!!! You have correctly stated the problem which XDG needs to
>> >> address
>> >> and solve. If 3rd party (commercial) applications are to succeed
>> >> for
>> >> Linux based systems, there must be a way for them to install on
>> >> system using at the most an RPM and a Deb package (or a Deb the
>> >> be
>> >> converted with Alien).
>> > That's no problem, just depend on file names instead of package
>> > or compile statically.
>> The infrastructure needed to rebuild packages for a set of
>> distributions is not overly complex (if sources are well-behaved
>> automake-like magic). It's much easier to build different packages
>> different distributions than to try to produce one-size-fits-all
> What I meant in the above quote was programs that only come in
> executable format with no sources provided.
Does not change anything the ISV has the sources of its software, so
if it does not want to release them it's its responsibility to set up
its own build system and create as many binary packages flavours as
its customers need.
As was proved by many projects setting up a system to build different
packages for different distributions is doable (as oppose to producing
the magical works everywhere unified binary).
> Actually a better way
> would be to provide distributions with precompiled object files and
> let us do the linking with proper versions of libraries but that is
> prone to sniffing symbols.
Relinking object files produced by different GCC versions is not
supported by the GCC team, so it may break without warning at any
More information about the xdg