> Date: Sat, 24 Nov 2007 11:27:39 -0800 > From: "Bastian, Waldo" <[EMAIL PROTECTED]> > To: "Stanislav Brabec" <[EMAIL PROTECTED]>, "Patryk Zawadzki" > <[EMAIL PROTECTED]> > Cc: [email protected], Thomas Leonard <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > > 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
