The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Package Management
Date: Sun, 22 Nov 2020 10:24:51 +1100	[thread overview]
Message-ID: <20201121232448.mwxq4kjjvpth4c4b@localhost.localdomain> (raw)
In-Reply-To: <CAC20D2OUZ1eMr7oYWtrLD_=58g-kSn6DrMceGghNaM+pOsAZbQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3858 bytes --]

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/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-11-21 23:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 21:32 Henry Bent
2020-11-21  0:55 ` Jeremy C. Reed
2020-11-21 17:50 ` arnold
2020-11-21 23:30   ` Gregg Levine
2020-11-22  1:17     ` Clem Cole
2020-11-22  1:39       ` Warner Losh
2020-11-24  7:35         ` Stuart Remphrey
2020-11-21 22:23 ` Clem Cole
2020-11-21 23:24   ` G. Branden Robinson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-01-24  4:27 Henry Bent
2017-01-24 17:06 ` Clem Cole
2017-01-24 17:46   ` Henry Bent
2017-01-24 18:58     ` Tim Bradshaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201121232448.mwxq4kjjvpth4c4b@localhost.localdomain \
    --to=g.branden.robinson@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).