diff --git a/documents/problems/packageMarkup.txt b/documents/problems/packageMarkup.txt new file mode 100644 index 0000000..e08475f --- /dev/null +++ b/documents/problems/packageMarkup.txt @@ -0,0 +1,101 @@ +LSB Specification + +Problem Statement: +------------------ + +The existing LSB Package Standard specifies a format (which hasn't +changed this century) and a tag content enumeration (most of which +has not changed this century, the major exception is RPMTAG_FILENAMES), +but doesn't address the problem of package metadata sufficiently directly. + +The specification (and the tools based on the spec) forbid certain +tags (RPMTAG_TRIGGERS), constrain other values (i.e. only + Requires: lsb >= X.Y +is permitted), and ignore other tags. This generally leads to +an arbitrary specification that cannot be usefully implemented +in any version of RPM. + +The metadata in a package (not just RPM) is moderately complicated, +and largely invisible because hidden with a binary format. + + + + +(Proposed) Solution: +-------------------- + +Choose a markup format that displays all of the metadata in a package. + +RPM (all versions of RPM since rpm-3.0.6) includes a very +simple XML markup to dump all the metadata in a package. The +existing widely deployed XML markup can be seen by typing, say, + rpm -q --xml bash + +A very short example that displays all 5 XML tags is: + + + + C + + + 924592 + + + iQIVAwUAUefxoglG/KLBBbneAQKTdw/9FHsbBZxBWb7OM4v1+QJBPe6rUTYr9tWu +YwkPqP0GOfT5zdjkocYmX9WAJNrztv0OQAdTDyOVvkIa/ewQ3HfNSMMdTwSoe0qd +AsUGmHbc2McUClT4JNVAIrZlmYOZ0rLTTSDeOFTS0JUIdmOCgL+0Cfl5mqvupWI+ +yTcqI5MuwrwrMHCkmSDX3rTCgmR5ZYbTsusD8JRLya2vA0rF8EGLfVvZPVKr4VY6 +7iDW2nc8l3TdO5HlGVHmsDc5Qz3uV7dWHHKlBdDZE2gua/hS/a75HewDXeTys2SH +lWGzCQbtbQMNYhays0qIZFyHdmuvXchnd+F8YEA3dRvPfvwn2paCouuhUMWENgxc +uZoBeo53bLe7/7xsmOdr1juK8IxFzQJyJxe3o1SDontk4pT9GNPWIkCJgQr5td9K +F3tCApsvtRX3dFU7Ed8MAUyrRzCoYhG/AVmZ8WAkYuszN6SfFJgbG39NAYiz5/Ec +d6lcLSgOjNqyGr35CRaIOn4dSoBJzrGFhjZSnK2DyJVjZ1lGZxjMN7kEri30hpnH +3f4BmoVFCrT69yioRfOTXHTf1paLvvJ1/z7TCX6fF39oUcH98HIa47Idvd1qEv29 +RPjb7yETUMS6byHecHKw+mWIXLNtKU9I1xRThsW1X1WsBzq/I6RtP9RZgUWkSbWA +IEzVfdVuj1A= + + +A sed(1) script could be used if any of + + + + + +are deemed too rpm-centric for package markup. The real goal of +using markup instead of binary packages is an attempt to unify +the representation of a package -- including dpkg -- in a WYSIWYG +format that is much easier to examine and understand. + +The hope is that better testing tools can be written using the +markup (rather than packages) as input, and that the non-LSB +*.deb packages might be usefully included. + +There are of course many other markups, including JSON/YAML, that +might be useful. I have described the --xml markup +which is already widely deployed in RPM. + +Solution Discussion Links: +-------------------------- + +THere are endless discussions of the relative merits of *.rpm vs *.deb +that have occurred over the years, mostly without any deep or complete +understanding of what metadata is contained in a package. + + +Solution Rationale: +------------------ + +The --xml option was added to rpm in order to supply a WYSIWYG +complete specification of what is in a LSB *.rpm package. + + +Distributions Support: +---------------------- + +All distro's that use rpm (that I know of) include the --xml option. + + +Verification Test: +------------------ + +Validation tests for the generated XML can be undertaken as needed. diff --git a/documents/problems/packageVersionComparison.txt b/documents/problems/packageVersionComparison.txt new file mode 100644 index 0000000..89a85f8 --- /dev/null +++ b/documents/problems/packageVersionComparison.txt @@ -0,0 +1,76 @@ +LSB Specification + +Problem Statement: +------------------ + +The LSB Package Standard does not specify how package (or dependency) +versions can be compared in order to detect "newer". Without the +ability to compare two versions unambiguusly, versions can only be +used for identification purposes, and equality is the only well defined +operation. Most (if not all) package managers are expected to +be able to upgrade/update a package with a version that is +later or newer. + +Note that this proposal is _ONLY_ for an LSB package version +and explicitly ignore both Epoch:/Release: which have other +more complex usage cases by existimng package managers. + + +(Proposed) Solution: +-------------------- + +Adopt a version scheme for the LSB Package Standard that can be +used for more than package version identification using equality. + +The naive consistent choice might be to document the version comparison in +rpm-3.0.6. However that choice is incompatible with Debian dpkg as well +as with extensions to version comparison that have been been deployed +by distros using rpm since rpm-3.0.6 was used. + +Adopting a MAJOR.MINOR.PATCH scheme (for LSB packages) is another +candidate. Adopting MAJOR.MINOR.PATCH is often used in software +engineering, and has a glibc strverscmp(3). If only digits are permitted +in the version strings, there is a good possiblity that both dpkg +and rpm might compare package versions identically. + +Another possibility would be to adopt semantic versioning: + http://semver.org +if there is a perceived need to use alphabetics and punctuation +as well as digits in LSB Package Standard versions. + +I am suggesting MAJOR.MINOR.PATCH using only digit strings +with only a "." period as a permitted delimiter, where both +MINOR and PATCH are optional, but MINOR must be specified +if PATCH is included in the version string. + +Solution Discussion Links: +-------------------------- + +The incompatibilities between RPM version comparison and +other version comparison schemes have been discussed many +many places. + + + + +Solution Rationale: +------------------ + +The solution was derived by noting that LSB Package Standard versions +is not well specified. + + +Distributions Support: +---------------------- + +Distribution support for what LSB adopts for LSB Packages is irrelevant. +Meanwhile there should be very few surprises in choosing MAJOR.MINOR.PATCH +versioning as described above. + + +Verification Test: +------------------ + +Test cases can be written as needed: the proposal is for adoption +of a version scheme that can be recommended and suggested as part +of the LSB Package Standard specification.