The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Package Management
@ 2020-11-20 21:32 Henry Bent
  2020-11-21  0:55 ` Jeremy C. Reed
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Henry Bent @ 2020-11-20 21:32 UTC (permalink / raw)
  To: TUHS main list

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

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

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-20 21:32 [TUHS] Package Management Henry Bent
@ 2020-11-21  0:55 ` Jeremy C. Reed
  2020-11-21 17:50 ` arnold
  2020-11-21 22:23 ` Clem Cole
  2 siblings, 0 replies; 13+ messages in thread
From: Jeremy C. Reed @ 2020-11-21  0:55 UTC (permalink / raw)
  To: Henry Bent; +Cc: TUHS main list

See The SPMS Software Project Management System
documented in the new/spms for 4.3BSD
http://www.retro11.de/ouxr/43bsd/usr/src/new/spms/doc/
(I couldn't find link to this at TUHS.)
I don't know about it but maybe that will help 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-20 21:32 [TUHS] Package Management 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-21 22:23 ` Clem Cole
  2 siblings, 1 reply; 13+ messages in thread
From: arnold @ 2020-11-21 17:50 UTC (permalink / raw)
  To: tuhs, henry.r.bent

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-20 21:32 [TUHS] Package Management Henry Bent
  2020-11-21  0:55 ` Jeremy C. Reed
  2020-11-21 17:50 ` arnold
@ 2020-11-21 22:23 ` Clem Cole
  2020-11-21 23:24   ` G. Branden Robinson
  2 siblings, 1 reply; 13+ messages in thread
From: Clem Cole @ 2020-11-21 22:23 UTC (permalink / raw)
  To: Henry Bent; +Cc: TUHS main list

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

On Fri, Nov 20, 2020 at 4:33 PM Henry Bent <henry.r.bent@gmail.com> wrote:

> I know I have asked this before, but I am curious about any new replies or
> insight.  How did package management start?
>
Really good question.   I thought the PKG_ADD we had on Masscomp in '83 was
grabbed from PWB 3.0.  Unfortunately, Warren's stuff does not include, but
that is known to missing things (like SCCS which was first distributed as
part of PWB 1.0 and every version after).

So here is what I remember ...

When we did the '85 /usr/group standard, one of the things we argued about
was how would an ISV >>deliver<< a binary *I.e.* 'interchange' between two
systems to use the TOPS-10/TOPS-20 terminology (which is actually what we
were using since most of us were familiar with same).   By the time we got
to IEEE P1003, the whole reason USTAR was created was to solve that - which
begat the famous Tar Wars of the Research (TAR format) *vs*. CPIO (AT&T)
types [USTAR was a compromise and as I have said previously, was picked due
to the code in Ken's original implementation of the header CKSUM so it had
an unintended extension mechanism and as ASCII - cpio was binary in those
days AND could not be extended so older readers could at least read a new
tape).

The 'install' was left to each ISV and the assumption had been you would
use a USTAR tape (and eventually the PAX program) to read the bits, but
each ISV did their own 'installer.'  The idea of keeping a system-wide DB
on what was installed was still in the future.    PWB 3.0/System III
PKG_ADD was primitive, but my memory is it was the first attempt.  I do
remember it was on a number of System III based systems but was very much
tied to installing the AT&T supplied SW - which I suspect was leftover from
the AT&T external maneuver of trying to supply everything and was difficult
to use by ISVs and I don't remember many doing so.

As you point out, the first commercial UNIX I remember that really tried to
solve it, was Ultrix which had something for both their own use and for
their ISV's (setld) - which frankly sucked and I personally hated and
railed against.  But to DEC's credit, it was there.  It was modeled after a
similar tool for VMS.  Truth is, for a while it was the best.  The biggest
thing that setld did (which in practice it did poorly) was trying to keep a
DB of what you installed so that an admin could type a command and see what
had been loaded, and when and also what licenses were installed to run
purchased software.  Basically, it was driven by field service and SW
licensing.

When FreeBSD 1.0 came out, the big thing Jordan Hubbard did (and was much
better than Linux installs for a long time) was work on install >>for a new
system<<.  He also created the idea of 'packages' which were all of the
thousands of UNIX tools that people had ported to FreeBSD and could
optionally be installed.  I think it really was the first of the same name
and most of the features we know.  By today's measure, again it was crude,
my memory is that unlike setld, since it was not managing licenses, he
didn't think to add a DB/log of what was being installed.  He did not try
to solve the 'update' problem when a new version of FreeBSD was released
BTW.  Basically, you needed to do a new install.

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 truth is, none of the Research UNIX, FreeBSD nor Linux really put the
effort that DEC, Masscomp, Sun, IBM, HP did in how to update a system.
*i.e.* I'm currently running version 10.13.5 and I want to get to 10.14.2
-- what needs to be installed and how will it affect already installed and
running ISV codes.  [ IMO Microsoft is the worst and Apple is not much
better].

Linux is a weird one.  Because of the 'open source' thinking, the idea of
keeping old binaries running is not the high order bit.  DEC, IBM, HP,
Masscomp, and to some extent SUN and SGI, because they had a market for
commercial SW, have tried to keep old binaries going.

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.    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).  The >>idea<< is that the current generation of package
tools, like setld of yesterday, will allow the admin to what's running on
the local system.

Clem

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-21 22:23 ` Clem Cole
@ 2020-11-21 23:24   ` G. Branden Robinson
  0 siblings, 0 replies; 13+ messages in thread
From: G. Branden Robinson @ 2020-11-21 23:24 UTC (permalink / raw)
  To: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-21 17:50 ` arnold
@ 2020-11-21 23:30   ` Gregg Levine
  2020-11-22  1:17     ` Clem Cole
  0 siblings, 1 reply; 13+ messages in thread
From: Gregg Levine @ 2020-11-21 23:30 UTC (permalink / raw)
  To: arnold; +Cc: Tuhs

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
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-21 23:30   ` Gregg Levine
@ 2020-11-22  1:17     ` Clem Cole
  2020-11-22  1:39       ` Warner Losh
  0 siblings, 1 reply; 13+ messages in thread
From: Clem Cole @ 2020-11-22  1:17 UTC (permalink / raw)
  To: Gregg Levine; +Cc: Tuhs

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

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
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: 4973 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-22  1:17     ` Clem Cole
@ 2020-11-22  1:39       ` Warner Losh
  2020-11-24  7:35         ` Stuart Remphrey
  0 siblings, 1 reply; 13+ messages in thread
From: Warner Losh @ 2020-11-22  1:39 UTC (permalink / raw)
  To: Clem Cole; +Cc: Tuhs

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

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: 6789 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] Package Management
  2020-11-22  1:39       ` Warner Losh
@ 2020-11-24  7:35         ` Stuart Remphrey
  0 siblings, 0 replies; 13+ messages in thread
From: Stuart Remphrey @ 2020-11-24  7:35 UTC (permalink / raw)
  To: tuhs

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] Package Management
  2017-01-24 17:46   ` Henry Bent
@ 2017-01-24 18:58     ` Tim Bradshaw
  0 siblings, 0 replies; 13+ messages in thread
From: Tim Bradshaw @ 2017-01-24 18:58 UTC (permalink / raw)


On 24 Jan 2017, at 17:46, Henry Bent <henry.r.bent at gmail.com> wrote:
> 
> A quick look through some manuals shows that SunOS 3 (same timeframe) appears to have had a user-friendly initial setup program but it's not clear to me if it could be used after an installation to deinstall/modify/upgrade/etc. 

I don't think it could.  I also remember that SunOS 4's installer was somehow much more rudimentary.  I remember (for both) that things like patches were just tarballs or some equivalent: there was no registry I think.  However my memory is not reliable.

--tim


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] Package Management
  2017-01-24 17:06 ` Clem Cole
@ 2017-01-24 17:46   ` Henry Bent
  2017-01-24 18:58     ` Tim Bradshaw
  0 siblings, 1 reply; 13+ messages in thread
From: Henry Bent @ 2017-01-24 17:46 UTC (permalink / raw)


Perhaps I should have been more specific - I was referring to something
akin to Ultrix's setld or IRIX's inst, a user-friendly utility to
view/install/upgrade OS components as well as applications.

Ultrix setld first appeared in 2.0, which was 1987.  As far as I can tell,
IRIX inst appeared at about the same time.  A quick look through some
manuals shows that SunOS 3 (same timeframe) appears to have had a
user-friendly initial setup program but it's not clear to me if it could be
used after an installation to deinstall/modify/upgrade/etc.  I know almost
nothing about early HPUX, AIX, Domain/OS, etc. and hopefully some folks who
used them might be able to chime in.

And yes, setld is pretty bad.  I remember it being painfully slow on real
hardware, and it's still somewhat slow on emulated hardware.

-Henry

On 24 January 2017 at 12:06, Clem Cole <clemc at ccc.com> wrote:

> Hmmm - I suspect is depends on what you call package & installation
> management.  My guess is that all of the UNIX systems had something that
> were made from people that were birthed on DEC systems.   Certainly,
> Masscomp's RTU had something very much like VMS's scheme - why because the
> same person designed/influenced/implemented both of them (Tom Kent).
>  My guess is that SunOS, Apollo/Domain et al were similar - as at least
> they knew the importance of same.
>
> The problem I have with the question is that the managers we have today
> are much different than the managers we had then.   Even things as simple
> as BSD's pkg_add is different from RPM much less yum, apt or brew compared
> to the (shutter) setld (DEC's my least favorite).
>
> Clem
>
> On Mon, Jan 23, 2017 at 11:27 PM, Henry Bent <henry.r.bent at gmail.com>
> wrote:
>
>> The recent discussion of Solaris made me think - what was the first Unix
>> to have centralized package management as part of the OS?  I know that IRIX
>> had it, I think from the beginning (possibly even for the GL2 releases) but
>> I imagine there was probably something before that.
>>
>> -Henry
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170124/7e40ea0b/attachment.html>


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] Package Management
  2017-01-24  4:27 Henry Bent
@ 2017-01-24 17:06 ` Clem Cole
  2017-01-24 17:46   ` Henry Bent
  0 siblings, 1 reply; 13+ messages in thread
From: Clem Cole @ 2017-01-24 17:06 UTC (permalink / raw)


Hmmm - I suspect is depends on what you call package & installation
management.  My guess is that all of the UNIX systems had something that
were made from people that were birthed on DEC systems.   Certainly,
Masscomp's RTU had something very much like VMS's scheme - why because the
same person designed/influenced/implemented both of them (Tom Kent).    My
guess is that SunOS, Apollo/Domain et al were similar - as at least they
knew the importance of same.

The problem I have with the question is that the managers we have today are
much different than the managers we had then.   Even things as simple as
BSD's pkg_add is different from RPM much less yum, apt or brew compared to
the (shutter) setld (DEC's my least favorite).

Clem

On Mon, Jan 23, 2017 at 11:27 PM, Henry Bent <henry.r.bent at gmail.com> wrote:

> The recent discussion of Solaris made me think - what was the first Unix
> to have centralized package management as part of the OS?  I know that IRIX
> had it, I think from the beginning (possibly even for the GL2 releases) but
> I imagine there was probably something before that.
>
> -Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170124/18ce9651/attachment.html>


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] Package Management
@ 2017-01-24  4:27 Henry Bent
  2017-01-24 17:06 ` Clem Cole
  0 siblings, 1 reply; 13+ messages in thread
From: Henry Bent @ 2017-01-24  4:27 UTC (permalink / raw)


The recent discussion of Solaris made me think - what was the first Unix to
have centralized package management as part of the OS?  I know that IRIX
had it, I think from the beginning (possibly even for the GL2 releases) but
I imagine there was probably something before that.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170123/1d1fcbb6/attachment.html>


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-11-24  7:36 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-20 21:32 [TUHS] Package Management 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
  -- 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

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git