Sorry for reposting this one, but I thought it deserved a separate thread.
I've had an idea I've been thinking about for quite a while now which you guys might be interested in...
The idea is to provide developers with a standard way to specify dependencies within the original code - i.e. to move the specification of dependencies out of the package managers and had over the responsibility to the developers.
For example, let's say the dependencies are listed in a standard file called DEPENDENCIES within the home directory of the project code, and that the file has a standard syntax. It should be possible for package managers to read this information automaticially and use it to help create packages.
The advantages I see to this approach are:
1. The original developers are the people best placed to know what their code is dependent on
2. Giving them this responsibility should encourage them to ensure they preserve backwards compatibility when it is desirable to do so
3. It reduces the replication of work between different Linux distributions
4. It should make it easier for users to install different versions of the software - i.e. reduce "dependency hell" when they depart from the standard distibution.
The idea derives from ideas in Component-based software engineering (see http://en.wikipedia.org/wiki/Component- … gineering).
An important thing to note is that the dependencies would NOT be on packages, but rather on INTERFACES (basically these are features or contracts if you like). It would be up to the developers to decide which interfaces they provide, when they drop them, etc.
Here ends my essay. If any one is interested in the idea or knows of any efforts to get something like this happening then please let me know! I am interested in pursuing the matter further.
Zancarius mentioned autoconf on the other thread...
The main difference is that autoconf is program and I what I'd like to see is a formalised list of dependencies and interfaces provided.
One advantage of having a formal list of interfaces provided is that it encourages developers to think seriously about backwards compatibility and to declare it formally.
Another issue is that autoconf is only used sometimes. I'm looking for something that is nearly always included and doesn't mandate a particular build system, language, package manager or anything like that. It should be more like a package description, but probably simpler.
While I think of it another important point is that you can have run-time dependencies and compile-time dependencies. A DEPENDENCIES file could contain two sections - one section for runtime, one for compile time (plus possibly sections for other exotic stages of development or use).
My main desire is to make package management easier rather than compilation easier, but I could see autoconf and other build tools having an option to read some or all of its dependencies from the DEPENDENCIES file.
Please do not keep bumping your thread https://wiki.archlinux.org/index.php/Fo … te#Bumping
You can edit your posts using the button on the bottom right.