Package management could be greatly sped up if the header files were split into two separate files, one containing only the package's version, dependencies and conflicts and the other containing all of the information that people don't normally look at (license, author, changelog, etc)
Realistically speaking, all of the other package information could be gained by someone who cares to read it with something like "yum viewinfo thepackage". Some changes to createrepo and yum itself would probably make implementation of this rather simple.
On the subject of licenses, at least the GPL should exist in an RPM by itself and be a dependency of all packages covered under that license. The same could be done for other licenses as well and this would ensure the end user had a copy on system. Of course, this would require a bit of work by the package management team as the dependency would need to be added to all of those package. Even better, the proper license RPM could be dictated by the License field already in those files.
Thoughts?
-Jeremy
J French (me@semitekie.com) said:
Package management could be greatly sped up if the header files were split into two separate files, one containing only the package's version, dependencies and conflicts and the other containing all of the information that people don't normally look at (license, author, changelog, etc)
I suggest you look at the contents of the primary xml files in the repodata as opposed to other.xml and filelists.xml...
Bill
Bill Nottingham wrote:
J French (me@semitekie.com) said:
Package management could be greatly sped up if the header files were split into two separate files, one containing only the package's version, dependencies and conflicts and the other containing all of the information that people don't normally look at (license, author, changelog, etc)
I suggest you look at the contents of the primary xml files in the repodata as opposed to other.xml and filelists.xml...
Bill
yeah exactly. How much of that information is really required to update a system? To give a small example (right off the top): <package type="rpm"> <name>xmlsec1-openssl</name> <arch>x86_64</arch> <version epoch="0" ver="1.2.9" rel="8.1"/> <checksum type="sha" pkgid="YES">1424111620a512224a3456b34cd910e8bbc16ccc</checksum> <summary>OpenSSL crypto plugin for XML Security Library</summary> − <description> OpenSSL plugin for XML Security Library provides OpenSSL based crypto services for the xmlsec library </description> − <packager> Red Hat, Inc. http://bugzilla.redhat.com/bugzilla </packager> <url>http://www.aleksey.com/xmlsec/</url> <time file="1160095638" build="1152759006"/> <size package="81421" installed="213672" archive="214124"/> <location href="Fedora/RPMS/xmlsec1-openssl-1.2.9-8.1.x86_64.rpm"/> − <format> rpm:licenseMIT</rpm:license> rpm:vendorRed Hat, Inc.</rpm:vendor> rpm:groupDevelopment/Libraries</rpm:group> rpm:buildhostls20-bc2-14.build.redhat.com</rpm:buildhost> rpm:sourcerpmxmlsec1-1.2.9-8.1.src.rpm</rpm:sourcerpm> <rpm:header-range start="440" end="5936"/> − <rpm:provides /> − <rpm:requires /> </format> </package>
Much of this information is useless to anyone but a developer for or against a given package - things like packager, build host, even the description. If a user wants to see these, they should get the info from the secondary file. While this may not seem like a lot, it would make a difference if the user happens to be installing a lot of packages. IMO it should be as efficient as possible.
Not sure why I said changelog, but you get the idea.
On Saturday 26 May 2007, J French wrote:
On the subject of licenses, at least the GPL should exist in an RPM by itself and be a dependency of all packages covered under that license. The same could be done for other licenses as well and this would ensure the end user had a copy on system. Of course, this would require a bit of work by the package management team as the dependency would need to be added to all of those package. Even better, the proper license RPM could be dictated by the License field already in those files.
IANAL, but I don't think dependency to a license file on the filesystem or to a package providing one is really enough. There's rpm2cpio and "rpm --nodeps" etc so I believe the license file must be included in the package payloads.
On the other hand, once installed, some space could be saved eg. by hardlinking identical files, but that won't help with *.rpm file sizes, but we're not talking too big space savings here anyway. Some numbers: GPL text is about 18kB, GPL text gzipped is about 7kB (such as in package payload sizes), hardlinking identical /usr/share/doc/*/COPYING on my FC6 system would save about 3.4MB.
Ville Skyttä wrote:
On Saturday 26 May 2007, J French wrote:
On the subject of licenses, at least the GPL should exist in an RPM by itself and be a dependency of all packages covered under that license. The same could be done for other licenses as well and this would ensure the end user had a copy on system. Of course, this would require a bit of work by the package management team as the dependency would need to be added to all of those package. Even better, the proper license RPM could be dictated by the License field already in those files.
IANAL, but I don't think dependency to a license file on the filesystem or to a package providing one is really enough. There's rpm2cpio and "rpm --nodeps" etc so I believe the license file must be included in the package payloads.
On the other hand, once installed, some space could be saved eg. by hardlinking identical files, but that won't help with *.rpm file sizes, but we're not talking too big space savings here anyway. Some numbers: GPL text is about 18kB, GPL text gzipped is about 7kB (such as in package payload sizes), hardlinking identical /usr/share/doc/*/COPYING on my FC6 system would save about 3.4MB.
I was thinking there might be some issue along these lines as well (concerning the license).
IMO, every aspect of the system should be as efficient as possible, but if you have to download the license, then you have to download the license. I was mainly referring to the header information in primary.xml (see my response to Bill)