The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Stuart Remphrey <stu@remphrey.net>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Package Management
Date: Tue, 24 Nov 2020 15:35:21 +0800	[thread overview]
Message-ID: <CAD0_1ckDULeCbZC8rhi=-jpCPr+Sav2KSiuwEXUVfZntHPqBuw@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfp=jvCL5KAB_u78Spi4iaCUZLrunE6LUSod+vm4MZD3Hg@mail.gmail.com>

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

"When I was managing SunOS systems it seemed like everyone rolled their
own..."

Yep, IIRC, tarball or cpio tape, no tracking or update support. Lucky if
the ISV install script asked where to install it.


SunOS filesystem layout was thoughtfully designed though, when diskless &
diskfull systems were introduced supporting multiple architectures (2.5?
3.x?): CPU-architecture-specific and architecture-independent mount points,
directories for Sun, ISV and local apps, etc (/usr /opt /usr/local and
their variations), read-only /usr support (link writeables into /var).

Though, mostly just Sun used this flexibility/complexity, few ISVs: they
generally wanted their installs to be consistent across HP-UX, MIPS
RISC/os, Pyramid dualPort DC/OSx, Sequent (Dynix?), SunOS, (maybe-AIX??,)
etc; which made sense from a support training point of view.


Beyond ./configure; make; make install which I'd count as build but barely
packaging, I don't recall any packaging until Solaris pkgadd et al?

Unfortunately with pkgadd came patchadd & friends.
They did their level best to cross-patch random binaries and muddy the
patch/package interdependency-waters as much as humanly possible.

Partly as a result, the early OS/patch/firmware support matrices for
FibreChannel were horrible.
I'll probably have nightmares about that tonight...


On Sun, 22 Nov 2020, 09:40 Warner Losh, <imp@bsdimp.com> wrote:

>
>
> On Sat, Nov 21, 2020, 6:19 PM Clem Cole <clemc@ccc.com> wrote:
>
>> 1) No intention to slight debian in any way.
>> 2) dpkg was definitely an improvement over FreeBSds ports scheme. But...
>> In fact freebsd did have a pkg system for ports before that --- which was
>> basically similar to 1983 SysIII scheme
>>
>
> FreeBSD's ports/pkg system did keep track of what was installed on the
> system. There was a database in /var/db so pkg_delete could remove things
> and pkg_which to know what pkg a given file belonged to.
>
> It was first-ish, but there was some package system for the early linux
> root disks. I think this is how SLS started, but I might be misremembering.
> But despite being early, and being ported to other BSDs, it sucked at
> upgrading for 20-odd years until it was completely rewritten.... latter day
> pkg is so much better, though its repo management has been a little weak
> relative to the professional efforts in the linux world.
>
> /usr/ports none the less was ground breaking because it handled both the
> local patching, the build depends and the packaging under one umbrella.
> It's been on the whole a good thing and has reinvented itself several times
> over the years.
>
> When I was managing SunOS systems it seemed like everyone rolled their
> own. There was nothing like VMSINSTALL...
>
> Warner
>
> 3) also as I understand (and larry feel free to correct me here as a
>> better chronicler of things Linux than I) but I believe that the big thing
>> rpm added was the DB like DEC's setld and system Sun had used which us what
>> I was refering too.
>>
>> Pls remember that I was trying to chronicle the basic ideas and some of
>> the motivation which is what Henry asked.   And that the original driver
>> was to support ISVs installs.  So I was trying to explain the history of
>> what we did at the time.
>>
>> The be fair one of the more vocal people in the early 80s was Heinz who
>> occasionally add color here.  I remember Heinz trying to push us to an ABI
>> and not stop at an API.
>>
>> Today most of the ISVs have abandoned Unix except for the Mac. Msft and
>> the phones have taken that.  And the package mngr has been replaced by the
>> app store which has.much great use than any of the current Unix packaging
>> schemes.  Funny how the profit motive drove that.
>>
>> Working for one of the few ISVS that do package SW for Unix we basically
>> support two schemes.  Apple Mac installs and RPM because that is were the
>> primary customer base has been.   I'd not about goodness or being better or
>> being first.  It's economic (Larry and I bemoan this a lot).
>>
>> So pls don't take it as a comment about anything other than trying to
>> answer as much of the early history as I could.
>>
>> Heinz, Jon, Larry you all lived this on the commercial side.   Care to
>> add anything?
>>
>> Clem
>>
>> On Sat, Nov 21, 2020 at 6:31 PM Gregg Levine <gregg.drwho8@gmail.com>
>> wrote:
>>
>>> Hello!
>>> I, myself normally run Slackware Linux. It uses package management in
>>> the form of compressed tar files, and a flat file store of the names.
>>> It also has a tool which when run will show the user what's there, and
>>> what they do if need be. In fact Slackware predates Red Hat by about
>>> four years. (Pat and his CS professor introduced themselves to one
>>> much earlier one, which was SLS. Neither liked it, and the Prof was
>>> convinced that Pat could do better.)
>>> -----
>>> Gregg C Levine gregg.drwho8@gmail.com
>>> "This signature fought the Time Wars, time and again."
>>>
>>> On Sat, Nov 21, 2020 at 1:54 PM <arnold@skeeve.com> wrote:
>>> >
>>> > Things were pretty much ad hoc.  Commercial software likely came
>>> > as tar/cpio tapes to install however the vendor wanted. Free software
>>> > was from USENET in source code, so again, however people wanted.
>>> >
>>> > The AT&T Unix PC (7300 / 3B1) in the late 80s had a file format
>>> > for installing software from floppy and tracked what was installed,
>>> > but that was unique to it.
>>> >
>>> > Package managers as we know them today really became a big thing
>>> > with Linux. Redhat's RPM was one of the earliest.
>>> >
>>> > My two cents; I'm sure others remember it differently.
>>> >
>>> > Arnold
>>> >
>>> > Henry Bent <henry.r.bent@gmail.com> wrote:
>>> >
>>> > > Hello All,
>>> > >
>>> > > I know I have asked this before, but I am curious about any new
>>> replies or
>>> > > insight.  How did package management start?  Were sites keeping
>>> track of
>>> > > packages installed in a flat file that you could grep (as god
>>> intended)
>>> > > somewhere, or were upgrades and additions simply done without
>>> significant
>>> > > announcement?  At what point did someone decide, 'Hey, we need to
>>> have a
>>> > > central way to track additional software"?
>>> > >
>>> > > I know of DEC's setld and SGI's inst in the latter half of the
>>> '80s.  What
>>> > > was the mechanism before that?
>>> > >
>>> > > -Henry
>>> >
>>>
>> --
>> Sent from a handheld expect more typos than usual
>>
>

[-- Attachment #2: Type: text/html, Size: 8944 bytes --]

  reply	other threads:[~2020-11-24  7:36 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 [this message]
2020-11-21 22:23 ` Clem Cole
2020-11-21 23:24   ` G. Branden Robinson
  -- 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='CAD0_1ckDULeCbZC8rhi=-jpCPr+Sav2KSiuwEXUVfZntHPqBuw@mail.gmail.com' \
    --to=stu@remphrey.net \
    --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).