22 Nov
2020
22 Nov
'20
5:24 a.m.
At 2020-11-21T17:23:45-0500, Clem Cole wrote:
Roll forward a couple of years and Linux eventually
picked up Jordan's
basic installer framework which vastly improved the out-of-box for
some of the Linux distros. But the important thing that RH did beyond
FreeBSD was to create RPM, which added a setld like DB to the scheme,
not for licenses, but so that you could easily do updates, add
options, etc. They combined Jordans install ideas and packages ideas,
which was cool for a system where you got/get everything from the
distro.
The complete lack of mention of dpkg and the Debian package format is an
error in your narrative. According to rpm.org, the "first commit" to
the rpm package management software was on November 27, 1995[1].
By this time, dpkg had already been around for over a year; you can find
Ian Jackson's release announcement of dpkg 0.93.63 in July 1995[2], and
dpkg's own "ChangeLog.old" file in its source tree documents its history
back to August 1994.
So ... now we have apt-get - which for what it is,
works pretty well
but, it still does not solve a problem someone like my firm has that
sells commercial SW.
It is worth noting that apt also originated in Debian, largely developed
by Jason Gunthorpe but originally uploaded by Scott Ellis in April
1998[3]. Despite apt's popularity and obvious technical advantages in
upgrade management (a cycle-breaking dependency analyzer)--it drew
grudging admiration even from many in the community who abhorred
uttering the words "Debian", "GNU/Linux", or both--and a deliberately
package-format-agnostic architecture, RPM-based distributions resisted
adopting it for years until Conectiva, a commercial distribution from
Brazil, wrote the requisite back-end for rpm support (apt-rpm)[4].
FWIW: Since I actually wrote the spec for it inside
Intel, I can tell
you what the design/goal/direction to tell the install teams in that
my employer distributes using RPM and >>is suppose<< to work
unmodified with an RPM-based install (*i.e.* be 'socially compliant'
to the norms of a more commercial-like Linux site). The >>idea<< is
that the RPMs are supposed to be able to automatically converted to
Yum and a few other formats (check the specs here for each tool,
however -- this is not a warranty from me - YMMV -- just telling what
I >>personal<< scream at the team when I discover they did not test
properly as sometimes they do break that - which can cause big issues
when trying to install on a supercomputer).
These norms tend to be distribution-specific. Even where technology is
the same, the norms that produce integration can differ. Little about
Unix kernels prescribes any particular filesystem hierarchy, for
instance.
It has often been observed that what quality the Debian system enjoys is
less due to its technological advantages--though IMO these are clear in
package format (deb), source package format (dsc) and administration
tools--but in Debian's culture of writing prescriptions for a consistent
system configuration in its Policy Manual[5], of maintaining automated
checking tools for compliance with those prescriptions[6][7], and of
being willing to gate releases on the lack of such compliance. The last
used to be a point of emphatic derision by rival distributions, most of
which were funded by venture capital and thus motivated to emphasize
cadence over technical quality, the former property being more easily
measured by non-specialists, deep-pocketed and otherwise.
Regards,
Branden
[1] https://rpm.org/timeline.html
[2] https://lists.debian.org/debian-devel/1995/07/msg00009.html
[3] https://lists.debian.org/debian-devel-changes/1998/04/msg00140.html
[4] https://lwn.net/Articles/30728/
[5] https://www.debian.org/doc/debian-policy/
[6] https://lintian.debian.org/
[7] https://piuparts.debian.org/