From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19112 invoked from network); 21 Nov 2020 22:24:53 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2020 22:24:53 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id CC3FA9CC21; Sun, 22 Nov 2020 08:24:51 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EF36193F9F; Sun, 22 Nov 2020 08:24:14 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="UDjikf0v"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A291D93F9F; Sun, 22 Nov 2020 08:24:12 +1000 (AEST) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by minnie.tuhs.org (Postfix) with ESMTPS id E4C3593DAD for ; Sun, 22 Nov 2020 08:24:11 +1000 (AEST) Received: by mail-qk1-f179.google.com with SMTP id q22so12643656qkq.6 for ; Sat, 21 Nov 2020 14:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NH2bnSHg1HC4tUZB1wIvWZEa6Fq+EwLSNqkvkpw+opU=; b=UDjikf0vdiqh4w/vokB6URnMC4+jWZ1x6bCjxr7Xweywle+poPBogoO0UuxxixI4yx Z1oxpWpkiWdO4GtySw/SxF5RElskvzt+M3w2Oxe+Zxsy5/8hD7hneMhtItOdMkkr7uCr n+HBpGtc8SgwiGKNH+8hxQR7+L25nEFNLvYuw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NH2bnSHg1HC4tUZB1wIvWZEa6Fq+EwLSNqkvkpw+opU=; b=pmATfygfQ0sRpUIzkp//YR29vOY2BwuEsNpfg1Jz5Hwt+pcNt7i7b+WjsWzFwh8gw1 fGYXmZuxzLeTTv5dd1OL/3LxfJY6pVpZVRvkIb94wXzHOtS9Wnb7tcsa8dIk8mOJ8xQM Xi7C7BwRyLyUpgMdAfaEWu2AXBl3j3E3eWdjkbcVlCjuyZtFZQm9ANwcNYXNYeC3GOF3 pZ2JUWhC6nwPVqm+t5jFOGGq5XcERQt45ljvZEOxcvx6506nM5KTJsReYU645SXYemkt cncPL1/daL1lpENJUeEXNwTh7tSq7JETqyIeA7BJepRk8RBpd6XKAj2GlPGKR5GFLLXA QtHQ== X-Gm-Message-State: AOAM530+Ky0Vrgzp0bQcKfALKpCwYVLyYm2jHywAN+kZ4/J5Nzz8ZVgI FrkM/jReDOeQ4fXLAORAEwvJYPwUOtQglnTOJg/OnS0MRpTPjKEHVFA= X-Google-Smtp-Source: ABdhPJzOgL0a7gXgdW5UQ6SbebQn/LgvDumgKjc9QfRjfHcHgHbUBbNT1bJP3V2DzT6GnJ8fkfyn5VFiRHnod0/RUus= X-Received: by 2002:a37:ba82:: with SMTP id k124mr22716433qkf.25.1605997450684; Sat, 21 Nov 2020 14:24:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Sat, 21 Nov 2020 17:23:45 -0500 Message-ID: To: Henry Bent Content-Type: multipart/alternative; boundary="0000000000008f07cb05b4a56b55" Subject: Re: [TUHS] Package Management X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000008f07cb05b4a56b55 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 20, 2020 at 4:33 PM Henry Bent 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 --0000000000008f07cb05b4a56b55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On F= ri, 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 r= eplies or insight.=C2=A0 How did package management start?=C2=A0=C2=A0
Really good quest= ion.=C2=A0 =C2=A0I thought the PKG_ADD we had on Masscomp in '83 was gr= abbed from PWB 3.0.=C2=A0 Unfortunately, Warren's stuff does not includ= e, but that is known to missing things (like SCCS which was first distribut= ed 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 th= e things we argued about was how would an ISV >>deliver<< a bin= ary I.e.=C2=A0'interchange' between two systems to use the T= OPS-10/TOPS-20 terminology (which is actually what we were using since most= of us were familiar with same).=C2=A0 =C2=A0By the time we got to IEEE P10= 03, 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) typ= es [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 ha= d 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 assumpt= ion had been you would use a USTAR tape (and eventually the PAX program) to= read the bits, but each ISV did their own 'installer.'=C2=A0=C2=A0= The idea of keeping a system-wide DB on what was installed was still in the= future.=C2=A0 =C2=A0 PWB 3.0/System III PKG_ADD was primitive, but my memo= ry is it was the first attempt.=C2=A0 I do remember it was=C2=A0on a number= of System III based systems but was very much tied to installing the AT&am= p;T supplied SW - which I suspect was leftover from the AT&T external m= aneuver of trying to supply everything and was difficult to use by ISVs and= I don't remember many doing so.=C2=A0

As you point out, the fi= rst commercial=C2=A0UNIX I remember that really tried to solve it, was Ultr= ix which had something for both their own use and for their ISV's=C2=A0= (setld) - which frankly sucked and I personally hated and railed against.= =C2=A0 But to DEC's credit, it was there.=C2=A0 It was modeled after a = similar tool for VMS.=C2=A0 Truth is, for a while it was the best.=C2=A0 Th= e 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 a= nd see what had been loaded, and when and also what licenses were installed= to run purchased software.=C2=A0 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 w= ork on install >>for a new system<<.=C2=A0 He also created the = idea of 'packages' which were all of the thousands of UNIX tools th= at people had ported to FreeBSD and could optionally be installed.=C2=A0 I = think it really was the first of the same name and most of the features we = know.=C2=A0 By today's measure, again it was crude, my memory is that u= nlike setld, since it was not managing licenses, he didn't think to add= a DB/log of what was being installed.=C2=A0 He did not try to solve the &#= 39;update' problem when a new version of FreeBSD was released BTW.=C2= =A0 Basically, you needed to do a new install.

Roll forward a cou= ple of years and Linux eventually picked up Jordan's basic installer fr= amework which vastly improved the out-of-box for some of the Linux distros.= =C2=A0 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.=C2=A0 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.=C2=A0 i.e. I'm currently run= ning version 10.13.5 and I want to get to 10.14.2 -- what needs to be insta= lled and how will it affect already installed and running ISV codes.=C2=A0 = [ IMO Microsoft is the worst and Apple is not much better].
=
Linux i= s a weird one.=C2=A0 Because of the 'open source' thinking, the ide= a of keeping old binaries running is not the high order bit.=C2=A0 DEC, IBM= , HP, Masscomp, and to some extent SUN and SGI, because they had a market f= or commercial=C2=A0SW, have tried to keep old binaries going.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">
So ..= . now we have apt-get=C2=A0- which for what it is, works pretty well but, i= t still does not solve a problem someone like my firm has that sells commer= cial=C2=A0SW.=C2=A0 =C2=A0 FWIW:=C2=A0 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=C2=A0distributes 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 Linu= x site).=C2=A0 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 d= iscover they=C2=A0did not test properly as sometimes they do break that - w= hich can cause big issues when trying to install on a supercomputer).=C2=A0= The >>idea<< is that the current generation of package tools, = like setld of yesterday, will allow the admin to what's=C2=A0running on= the local system.

=
Clem
--0000000000008f07cb05b4a56b55--