standard dependancy system

[Kai-Uwe Behrmann]

> 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>
> Message-ID:
> 	<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
> package
> > 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. 
> 
> Cheers,
> Waldo

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 
say?

Scenarios:
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 
run.
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 
hard.
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.


Proposal:
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 
for distributors.
configure --help should then show something like:

   --prefix=[/to/your/like]
NOT FOR DISTRIBUTORS 
Dont use below switches or distribute the package with a appropriate 
modified package name
   --disable-feature-A
   --disable-feature-B
END OF END DISTRIBUTORS DISALLOWED SWITCHES
   --enable-debug                       debug version [default disable]
   --disable-dependency-tracking        no dependencies [default check]
   --help

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 
line input.

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org