The interface names would be controlled by the developers and would be the same regardless of distro, although the exact way the interfaces would be spread across packages would vary. Interface versions should be more stable than package numbers - package names bump up whenever the implementation changes. On the other hand if an interface is to be useful it needs to be relatively stable.
Is it a solution in search of a problem? Well APIs and plugin archectures are used elsewhere to manage large projects and to allow disparate sets of programmers to work together. The Jack audio project is just one example of the power of an interface in action in Linux. A standard for specifying interfaces may encourage more of this sort of thing. And it doesn't need universal uptake to get things going - even if just some projects started using it might be enough to prove useful.
]]>If that's the case, then there's no benefit from a DEPENDENCIES file as that information is already available at upstream's website normally (ignoring autoconf et. al.). Most projects I know do have an INSTALL or similar file which specifies basic dependencies already. Synchronizing the syntax would be good but unless the issues above are dealt with not much benefits to be had IMO.
]]>The goal of a single cross-platform package manager is very gradiose. Not to say that it couldn't be tried. The reason I thought of DEPENDENCIES file is that it is a much smaller change and hopefully easier to get going. Also the fruits can be enjoyed by people who choose to use other package managers.
Indeed it is, but the reason I suggested it is because--as pointed out in this thread--there have been numerous attempts at a unified package manager or packaging standard for Linux distros. Sadly, many of these either withered on the vine or, typically, became useful to a fairly small niche. Package management is probably the most important part of a distribution and the most likely component to differentiate one distro from the next. If you want something to become widely adopted, the best thing to do is to avoid niches as much as possible. Since every major distribution has its own form of package management, there is a tremendous amount of inertia that fights against any form of "standard" package management. Add to that the nature of open source and the fact that most distributions have ports of other distributions' major package management--or at least wrappers to support other distros' packages--and you find that standardization becomes a curio for mental exercise more than a necessity.
Personally, I think that this pursuit of a "standard" method of package management is a solution looking for a problem and fundamentally ignores several critical issues that are necessary for adoption. Starting with a platform that has virtually no package management or support for F/OSS projects, like Windows (okay, there's Ninite and others... I don't count Windows Update), and that is only integrating a store come its next major release might be worth considering. If you want to avoid the risk of obscurity, particularly in a world where package managers are already well established, you have to do something different to make yourself stick out. Otherwise you encounter people like me who don't really see much of a point to it. Further, as a developer, why would I want to worry about packaging something myself? Let the maintainers do that if they want it for their platform. If users want it that bad, they can download the sources and install it themselves.
]]>Currently we have package maintainers doing this work. In many cases I could see developers being happy enough to have a trusted package maintainer keep the document up to date if that was really required. If you are putting the numbers into a Arch package, why not commit them to a file in the original location too? The fact that package management software was using the file would be enough to ensure the file was kept up to date.
The goal of a single cross-platform package manager is very gradiose. Not to say that it couldn't be tried. The reason I thought of DEPENDENCIES file is that it is a much smaller change and hopefully easier to get going. Also the fruits can be enjoyed by people who choose to use other package managers.
I also like the emphasis on interfaces rather than just packages. Coming up with a versioning system would be part of the design task. It couldn't be Semantic Versioning though because that's for packages. Patch numbers and minor aren't relevant, and there needs to be a mechanism to allow for backward-compatible interfaces.
]]>The idea is interesting, but I'm not convinced that targeting developers for this is necessarily the best thing. The fact is that developers often have enough on their plate if they target a wide variety of platforms (*BSD, Linux, OS X, Windows) and sometimes they write code that's managed by tool-specific package management system (think PyPI). Further, since different distros often have different goals, you'll find a great deal of diversity in the "default" configuration of software packages from distro to distro. Thus, it would need to be something that's targeted more or less toward package maintainers--they're the ones who know best about the slated goals and objectives of their respective distributions. I realize from a 50,000 foot review, something that superficially describes dependencies is inherently a good thing, but I can't really help myself from seeing it get muddied the instant disparate configurations are added into the mix.
The idea of depending on specific APIs is interesting since there isn't really any prescribed standard for version naming that describes when, specifically, a feature is added or dropped (well, there's always semantic versioning--but let's face it, not everyone follows it and not everyone who does follow it follows it correctly). The only problem is that if this isn't something that's somehow automatically generated, it then becomes another document-like entity the developer is left to maintain, and we all know that everyone keeps their documentation completely up to date.
Edit: The more I think about it, the more I realize that the best way to gain momentum for this sort of thing would be to have a truly cross-platform package manager that works on Linux, BSD, OS X, Windows, et al. Otherwise, it's fated to die on the vine of obscurity. In a manner, a meta-manager of sorts that could be interfaced with existing package managers (e.g. pacman) would be the path of least resistance.
]]>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.
You mean like autoconf?
]]>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.
]]>Linux need rules, where is what going after installing, everything else is same, you can call it deb, tar.xz or rpm.... Same story is about libs, versions and else...
There are such rules: https://en.wikipedia.org/wiki/Filesyste … y_Standard
And honestly, the majority of packages I've ever installed on any distribution *tend* to follow that fairly nicely. Of course if you're building a package yourself, odds are the Makefile is going to dump stuff in /usr/local instead of /usr, but that's (1) Still fairly consistant and (2) Not going against the spec anyway AND (3) Technically the "right" way to do it for non-package-manager-installed stuff.
]]>If anyone wants to make linux available to the masses must bring convenience to it.
]]>more like a package manager that andle rpm, deb, pkg.tar.{xz,gz}, ebuild and are able to build in any distro w minimal patch (maybe the python2 for example)
this is the only thing that is needed for linux, the extensions are only these extensions for the same packages
]]>