"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