I am bringing this up because I read this week's distrowatch article on Ravenports. The article makes it sound great, but I'm a "show-me-the-code" kinda guy and OMFG what a total mess - it makes the mozilla source tree look clean. Everything is in folders named bucketXX with no organization whatsoever and its a new project, so it will proabably only get worse.
I'm not saying there isn't a niche to be filled; there is, but Ravenports does not appear to be the answer.
A better solution would be to implement a new XDG specification for package specs - modeled after the desktop entry specification so that individual packages could output a single file that any distro could grok into their own format (for backward compatibility) or use directly. It could be added into the auto-tools suite or provided as a standalone script.
In addition to the (localized) keys in .desktop files, you would have package sizes, various checksums, (build) dependencies, source url, VCS url, maintainer, license, etc... See links at the end of this post for the random stuff some distros have in their package control files.
The reason I mention the desktop files is that they already contain much of the useful information and it is commonly already localized. For example:
* Localization (as in the desktop files) would allow more user friendly package management for non-english users because each translatable field "Key=" can have a corresponding "Key[lang]=" equivalent
* Mimetype (as in the desktop files) could be used by the package manager to handle an xdg-open of a file with no default handler for its Mimetype. Then the Exec field (as in the desktop file) could open it directly when it is installed... Come on even MS can handle this one (OK, they just use extensions, but the concept is the same)
* XDG specified Categories (as in the desktop files) could be used directly by package managers or mapped to legacy groups for backward compatibility. Using the same categories in the package manager as in the menu would make it more user friendly because it would be in the same relative location in the menu as it was in the graphical package manager. (see my jwm_intstall_menu_create script in the jwm-tools thread)
* The Icon field (as in the desktop file) could be used in graphical package managers, if available, to help the user quickly find what they installed.
Integrating the package info into the build process would use information that is normally already available anyhow and thus eliminate a lot of cross-distro duplicated effort. Most of the rest of the data that isn't contained in the desktop files, is already part of the build process (dependencies, build dependencies, sizes, checksums, maintainer etc...). Just have a package.spec.in file similar to the already existing package.desktop.in files
Other fields that could be useful:
Memory usage, CPU usage, ProjectURI, DonationURI, DocumentationURI, ScreenshotURI, BugsURI, SupportURI, WikiURI, ForumURI, etc...
Then you have the various ways of package splitting: from a simple slackbuild that produces one package per source tarball to splitting out binaries, libraries, development (DEV) files, documentation (DOC), data and localization (NLS) into separate packages. These can be split even further: NLS to each language such as package-*-NLS-en_GB. Split DEV so includes, pkgconfig files, etc... are in one package and the *.so links in a DEV-shared and *.a libs in a DEV-static. Split DOC into man, info, html, etc...
Moving the majority of this stuff into the upstream repositories would be better for upstream developers too. That way they can directly update changes to things like links, repositories, contact info etc... I still see distros that list a package's homepage as freshmeat, berlios, codeplex or google code and have even seen dead guys as the contact. It's better for up to date localization too.
Don't get me wrong, I'm not a big fan of autotools, but an improved version with hooks for different types of build failures that could be integrated with the package manager would be nice. Instead of a cryptic failure message, get something like Can't find "X": _Install, _Build, _BuildStatic, _Disable, _Quit (with install being the default if available followed by _Disable if it can just be disabled) ... but we need _something_. With no defacto standard, each distro does their own thing - badly. For example: Alpine Linux started as a small distro so they don't yet have package categories - just one big pile, but at least they aren't arbitrarily divided into ambiguous bucket** folders. If you look through the distro build systems of your favorite distro (all/any of them) 90% of the BS code is related to this one thing. If each package automatically output this to a specified format, most of that code could be eliminated.
Currently each distro painstakingly does the same thing differently. For example:
Alpine uses these
Arch uses these
Debian uses these
Fedora uses these and these
Solus uses these
Suse uses these
Ubuntu uses these
However the actual databases contain even more (and probably more, I just did the limit in ideone a couple of times)
- Arch
Architecture
Breaks
Bugs
Build-Depends
Build-Depends-Indep
Build-Ids
Changed-By
Closes
Conflicts
Depends
Description
Description-md5
Enhances
Filename
Homepage
Installed-Size
Keywords
Maintainer
MD5sum
Multi-Arch
Npp-Applications
Npp-Description
Npp-File
Npp-Mimetype
Npp-Name
Origin
Original-Maintainer
Package
Pre-Depends
Priority
Provides
Recommends
Replaces
Section
SHA1
SHA256
Size
Source
Standards-Version
Suggests
Tads2-Version
Tads3-Version
Tag
Task
Vcs-browser
Vcs-Git
Version
What fields should be added/removed from the list?
I'd like to hear comments... I'd like to see CPU usage, RAM usage and Mimetype for obvious reasons, but let me know if you have any insightful ideas.