standard dependancy system
ku.b at gmx.de
Sun Nov 25 03:44:37 PST 2007
> Date: Sat, 24 Nov 2007 11:27:39 -0800
> From: "Bastian, Waldo" <waldo.bastian at intel.com>
> To: "Stanislav Brabec" <sbrabec at suse.cz>, "Patryk Zawadzki"
> <patrys at pld-linux.org>
> Cc: xdg at lists.freedesktop.org, Thomas Leonard <talex5 at gmail.com>
> <1B47D24854C7BC4FA8DA28BEBB59B0BA02A19F57 at orsmsx419.amr.corp.intel.com>
> > I do it as well (sometimes). But I doubt that anybody from distro
> > maintainers read each line of config.log for each update of each
> > to verify, that all features were included.
> Which is funny in a really sad kind of way, because you would think that
> any company whose main business it is to compile other people's software
> would try a little bit harder to get consistent results.
Agreed. Let me extend this aspect even further.
Is a package featuring a plug-in system still the same when not delivered
with its plug-ins? Should at least the name say that it is not complete?
Who decides about this? Should'nt the original maintainer have a last
Users, IMHO, should get informed about missing features and get the
package compiled and running. It is up to the maintainer to find ways how
to present a feature summary. Many packages adapt to a style in printing
out a short informational feature/dependency summary at end of a configure
It is the users responsibility to ignore missing features, like for
instance missed plug-ins.
Distributors should be forceable to meet quite other standards.
Dependencies and belonging features should eighter be ignoreable or die
Sometimes packagers even figure out the switch to disable important
features. They dont know if this is intended or not.
Even functionality can suffer. Compiled binaries may render incompatible
on other machines, because some distribution requirements where not meet.
These may be my personal opinions. Even though I would like to enforce
them through all stages of software development and ditribution.
Of course I can understand that distributors do not know much about each
of hundreds of packages. Sometimes even a original maintainer has problems
to know about all sides of a package ;-)
Anyway a package modified to some extend is acceptable. If a certian
border is crossed, the package should not any longer bear the original
name. It becomes derived or whatever called software package and should
clearly express this in a appended name.
To help distinguishing for user versus distribuor usage, I'd propose a
configure switch marking.
This allowes to know about the intention what is a appropriate change
configure --help should then show something like:
NOT FOR DISTRIBUTORS
Dont use below switches or distribute the package with a appropriate
modified package name
END OF END DISTRIBUTORS DISALLOWED SWITCHES
--enable-debug debug version [default disable]
--disable-dependency-tracking no dependencies [default check]
Is this practical?
The disadvantage is that configure can not automatically detect that it is
in distribution mode, or if manually invoked and its status lines get a
chance that they are really read.
Is there a standard variable showing that configure runs automatically?
Alternatively a last user query can be required in case of non
distribution allowed options where triggered. A automatic system should be
incapable to type YES/NO in the command line if configure requires command
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the xdg