-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clayton wrote:
So a "enhancement" page on the wiki would be very nice. I know, however (for already having tried to do such things) that it's a very hard work.
I was thinking the same thing would be nice for the apt repositories. So often there is a new build of something showing up in the apt repositories... but no list of the delta/changes between the installed/previous version and the new version. I've never spoke up asking for it because I know that a lot (most) of the stuff I use from apt is user contributions, and I'm grateful it's there... and as you say, it's a lot of hard work to add the delta info (even if you're the developer).
It certainly is. IMHO the best option is to have RSS/RDF/Atom feeds, like on my site: http://linux01.gwdg.de/~pbleser/rss.php or as on Packman: http://packman.links2linux.de/rdf/packman_en.rdf The problem is that what actually needs to be shown as for "delta information" comes from the software authors, not from the packager, because a newer package is almost always because of a new upstream version (sometimes also because of bugfixes to the package itself, but that's maybe 5%). There is Changelog information inside RPM packages (e.g. "rpm -q --changelog sed") but that's for changes applied to the package itself, not to the software that's being packaged, so it's usually quite pointless to show that information. What makes it tedious is the fact that the packager would have to manually write the change information that applies to the new version. And it has to be done manually because: - - there's no common structure as where that information is stored: some have ChangeLog, some have NEWS, some only on their website, some have none (!) - - ChangeLog files are quite common but they're much too fine grained, noone wants to read all that (and it's not very helpful to end-users) - - NEWS files are not always present (I'd say in 30% of the projects, at most) and there's no standardized format and no way to automatically retrieve change information from those files (unless you do some really nasty text file parsing magic, but that'll never work for more than 70% of such files) So, to summarize: 1) either the packager has to manually collect the change information from various sources, 2) or the authors of the software have to come up with some standardized, machine-parseable (e.g. XML-based) file format that could automatically be aggregated. (1) is tedious (2) probably will never be possible, as all the FOSS authors would have to include such a file (and we'd already be happy if they would all integrate the patches we have to apply to their sources) IMHO the only real chance to have that in a near future is to: 1) bring all the 3rd party SUSE Linux packagers together 2) aggregate their repository information on opensuse.org (which also means defining a common infrastructure, technically speaking, such as providing Atom feeds of their package updates) 3) avoid duplication of RPM packages amongst those repositories, to reduce the amount of work every packager has, which will then give some more time to spend on adding such change information ;) RSS/RDF/Atom feeds seem to be the best fitting "technology" for such information. If every 3rd party package repository had such a feed, it could be aggregated into a single one on opensuse.org - From there on, we'd need to have it integrated into YaST2 and enable one-click installation of the packages that show up (including their dependencies). That would also involve things as YaST2 prompting "The suser-guru repository is currently not in your list. Do you want to add it ?", etc etc etc... But here we're coming back to the discussion on - - how to aggregate 3rd party package repositories - - how to define common policies and quality guidelines - - how to handle security, trust level and QA of those repositories (voting, cross-signing, ...) - - how to categorize them into stable/unstable/experimental etc etc etc... (read the many mails about that thread on this mailing-list) Personally, I have quite a lot of very palpable ideas on how to implement those processes, and I hope we'll be able to discuss them all, together (at least for people who have some background on packaging and maintaining such repositories), once the SUSE staff has some time to spend on it. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDLoqQr3NMWliFcXcRArceAJwLxp8nDh+yULEk+H5XuzTMkbTDVQCeJaaO Q+otID1pl+Pf36vZcGNY9aI= =GA8X -----END PGP SIGNATURE-----