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/