From owner-freebsd-libh Thu Mar 29 13:22:52 2001 Delivered-To: freebsd-libh@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-50.dsl.lsan03.pacbell.net [63.207.60.50]) by hub.freebsd.org (Postfix) with ESMTP id B87CE37B71B for ; Thu, 29 Mar 2001 13:22:49 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1F1AB66D83; Thu, 29 Mar 2001 13:22:49 -0800 (PST) Date: Thu, 29 Mar 2001 13:22:49 -0800 From: Kris Kennaway To: libh@freebsd.org, op-tech@openpackages.org Subject: PackageNG and OpenPackages Message-ID: <20010329132249.A6943@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As far as I can tell there isn't any communication between these two camps: OpenPackages on the one hand, and the nascent PackageNG developers on the FreeBSD side. There hasn't been much public progress on the PackageNG side (which has been talked about on and off for a long time, and I think actually predates OpenPackages), but given that both groups are looking to develop a revamped packaging system for FreeBSD (and others, on the OP side) it's sensible that there be some dialogue here to avoid unnecessary pain down the road when one of the projects comes to fruition and "stomps all over" the work of the other. Kris --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6w6eoWry0BWjoQKURAkD3AJ9AmlvfOsLBkDC9HWnLnSl3lxe6+gCgwmqv a2lMdyXVFSzdDdwLKulUK5o= =U0gw -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 13:42:31 2001 Delivered-To: freebsd-libh@freebsd.org Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (Postfix) with ESMTP id 3A5D037B71E for ; Thu, 29 Mar 2001 13:42:29 -0800 (PST) (envelope-from chrisc@vmunix.com) Received: by vnode.vmunix.com (Postfix, from userid 1005) id 6B1AB11; Thu, 29 Mar 2001 16:42:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by vnode.vmunix.com (Postfix) with ESMTP id 6066B49A13; Thu, 29 Mar 2001 16:42:23 -0500 (EST) Date: Thu, 29 Mar 2001 16:42:23 -0500 (EST) From: Chris Coleman To: Kris Kennaway Cc: libh@freebsd.org, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329132249.A6943@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does the PackageNG have a webpage? And, any idea how far along they are in their progress? The goal of Open Packages is to take the best features of each packaging system and incorporate them into one packaging system that can be adopted by all BSD groups. So I know we are interested in communicating. Chris Coleman Daemon News http://www.daemonnews.org Bringing BSD together On Thu, 29 Mar 2001, Kris Kennaway wrote: > As far as I can tell there isn't any communication between these two > camps: OpenPackages on the one hand, and the nascent PackageNG > developers on the FreeBSD side. There hasn't been much public > progress on the PackageNG side (which has been talked about on and off > for a long time, and I think actually predates OpenPackages), but > given that both groups are looking to develop a revamped packaging > system for FreeBSD (and others, on the OP side) it's sensible that > there be some dialogue here to avoid unnecessary pain down the road > when one of the projects comes to fruition and "stomps all over" the > work of the other. > > Kris > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14: 2:51 2001 Delivered-To: freebsd-libh@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 68FA137B72D for ; Thu, 29 Mar 2001 14:02:47 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2TM2Sg93287; Thu, 29 Mar 2001 14:02:29 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: kris@obsecurity.org Cc: libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329132249.A6943@xor.obsecurity.org> References: <20010329132249.A6943@xor.obsecurity.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010329140228S.jkh@osd.bsdi.com> Date: Thu, 29 Mar 2001 14:02:28 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I'm not sure both groups are actually working on the same problem, to be honest. From what I understand, OpenPackages is attempting a far more pragmatic approach to bridging existing ports/packages technologies so that all the *BSD (and perhaps Linux) groups have something more closely resembling a unified technology base. The PackageNG AKA libh project is working on something much more research-oriented and nobody is even willing to commit to a date when/if this will become an operational "product", it's that radically different. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14: 8:18 2001 Delivered-To: freebsd-libh@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 575EC37B71A for ; Thu, 29 Mar 2001 14:08:16 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2TM7sg23125; Thu, 29 Mar 2001 14:07:55 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: chrisc@vmunix.com Cc: kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: References: <20010329132249.A6943@xor.obsecurity.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010329140754K.jkh@osd.bsdi.com> Date: Thu, 29 Mar 2001 14:07:54 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 7 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does the PackageNG have a webpage? And, any idea how far along they are > in their progress? It's not that well organized. :) Like I said, consider it more of a pure research project for now. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14:20:13 2001 Delivered-To: freebsd-libh@freebsd.org Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (Postfix) with ESMTP id CC5E937B71F for ; Thu, 29 Mar 2001 14:20:07 -0800 (PST) (envelope-from chrisc@vmunix.com) Received: by vnode.vmunix.com (Postfix, from userid 1005) id 36C2A11; Thu, 29 Mar 2001 17:20:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by vnode.vmunix.com (Postfix) with ESMTP id 2F33F49A13; Thu, 29 Mar 2001 17:20:07 -0500 (EST) Date: Thu, 29 Mar 2001 17:20:07 -0500 (EST) From: Chris Coleman To: Jordan Hubbard Cc: kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329140754K.jkh@osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Does the PackageNG have a webpage? And, any idea how far along they are > > in their progress? > > It's not that well organized. :) Like I said, consider it more of a > pure research project for now. > > - Jordan > It sounds like PackageNG is working on only a small part of the project we are tackling and can probably be assimilated into the OP project at the appropriate time. However, I am not entirely clear as to the PackageNG goals, but it doesn't appear that we can do much about them until they have progressed further. So I guess OP just needs to keep plugging along. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14:27:54 2001 Delivered-To: freebsd-libh@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id CFA5837B71B for ; Thu, 29 Mar 2001 14:27:51 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2TMRgg84214; Thu, 29 Mar 2001 14:27:42 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: chrisc@vmunix.com Cc: kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: References: <20010329140754K.jkh@osd.bsdi.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010329142742L.jkh@osd.bsdi.com> Date: Thu, 29 Mar 2001 14:27:42 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It sounds like PackageNG is working on only a small part of the project we > are tackling and can probably be assimilated into the OP project at the > appropriate time. However, I am not entirely clear as to the PackageNG > goals, but it doesn't appear that we can do much about them until they > have progressed further. Well, I'm not sure I'd use the word "assimilated" - you guys are sounding like the Borg now. :) Let's just say that we all hope some of its technology is relevant to other projects, both in whole or in part, and that both efforts manage to attract enough people to make this whole issue something of genuine relevance to our daily lives. I also think that there's genuine merit in pursuing parallel lines of development, just as all engineering has its pure research and nuts-and-bolts facets which are not mutually exclusive. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14:32:17 2001 Delivered-To: freebsd-libh@freebsd.org Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (Postfix) with ESMTP id E984137B720 for ; Thu, 29 Mar 2001 14:32:12 -0800 (PST) (envelope-from chrisc@vmunix.com) Received: by vnode.vmunix.com (Postfix, from userid 1005) id 61A3311; Thu, 29 Mar 2001 17:32:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by vnode.vmunix.com (Postfix) with ESMTP id 4A3F949A13; Thu, 29 Mar 2001 17:32:12 -0500 (EST) Date: Thu, 29 Mar 2001 17:32:12 -0500 (EST) From: Chris Coleman To: Jordan Hubbard Cc: kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329142742L.jkh@osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Well, I'm not sure I'd use the word "assimilated" - you guys are > sounding like the Borg now. :) Let's just say that we all hope some of More like the Highlander: There can be only one. :-) -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 14:44:10 2001 Delivered-To: freebsd-libh@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 3427337B71D for ; Thu, 29 Mar 2001 14:44:05 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f2TMhYl13098; Thu, 29 Mar 2001 14:43:34 -0800 Date: Thu, 29 Mar 2001 14:43:34 -0800 From: Brooks Davis To: Jordan Hubbard Cc: chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages Message-ID: <20010329144334.A9413@Odin.AC.HMC.Edu> References: <20010329140754K.jkh@osd.bsdi.com> <20010329142742L.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010329142742L.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Thu, Mar 29, 2001 at 02:27:42PM -0800 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2001 at 02:27:42PM -0800, Jordan Hubbard wrote: > Well, I'm not sure I'd use the word "assimilated" - you guys are > sounding like the Borg now. :) Let's just say that we all hope some of > its technology is relevant to other projects, both in whole or in > part, and that both efforts manage to attract enough people to make > this whole issue something of genuine relevance to our daily lives. I think the best solution at this time is for the two projects to keep each other in mind, but leave it at that. For OP this means thinking about package building in such a way that building package bundles other then OP packages is plugable. For example, what ever we might think of RPMs there's some value in allowing someone to maintain a module that lets you use the packaging framework to build them. Or for that matter, .deb packages or whatever MacOS X uses or (horror of horrors) InstallShield packages for Windows. We can and should maintain our own package system (if for no other reasion then the fact that maintianing thousands of packages in an integrated framework will give us insights other's just won't have), but that doesn't mean we shouldn't support other systems. For PackageNG, this means keeping an eye on OP any lobbying for features you need. Once something more or less works, building a module for OP to generate PackageNG packages. If PackageNG lives up to its promise/hype it seems likely OP could adopt it. The two projects have a significant intersection, but they aren't attacking the same problem. In any case, as Jordan says, two projects can well be better then one, especialy when they attack the same problem space from different, but equaly legitimate directions. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6w7qVXY6L6fI4GtQRAszbAJ4pn+4E7OR8h4/tW3mo1YyKEVpOBwCgrJNi i9v32ZuJsDCjV5DEB0bLKWk= =5wDc -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 15:19:51 2001 Delivered-To: freebsd-libh@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id D6F5637B71F for ; Thu, 29 Mar 2001 15:19:48 -0800 (PST) (envelope-from mwm@mired.org) Received: (qmail 69396 invoked by uid 100); 29 Mar 2001 23:19:47 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15043.49939.888504.953014@guru.mired.org> Date: Thu, 29 Mar 2001 17:19:47 -0600 To: Jordan Hubbard Cc: chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329140754K.jkh@osd.bsdi.com> References: <20010329132249.A6943@xor.obsecurity.org> <20010329140754K.jkh@osd.bsdi.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard types: > > Does the PackageNG have a webpage? And, any idea how far along they are > > in their progress? > It's not that well organized. :) Like I said, consider it more of a > pure research project for now. The libh project has a home page - and you even wrote most of it. Isn't that what PackageNG is, for now? . http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 15:21:45 2001 Delivered-To: freebsd-libh@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 2457137B71A for ; Thu, 29 Mar 2001 15:21:43 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2TNKug84474; Thu, 29 Mar 2001 15:20:57 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: brooks@one-eyed-alien.net Cc: chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010329144334.A9413@Odin.AC.HMC.Edu> References: <20010329142742L.jkh@osd.bsdi.com> <20010329144334.A9413@Odin.AC.HMC.Edu> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010329152056I.jkh@osd.bsdi.com> Date: Thu, 29 Mar 2001 15:20:56 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, I agree with all of this. This is also why I feel that any work which goes into establishing *taxonomy* will never be wasted. Let's say that someone put some serious effort (and I think that'd be merited BTW) into establishing what a merged /usr/ports and /usr/src might look like. Just for purposes of argument, let's say it also ended up looking like this: METADATA.xml archivers devel japanese palm astro java print russian audio editors korean science benchmarks emulators lang security biology french mail shells cad ftp math system chinese games mbone sysutils comms german misc ukrainian converters graphics net vietnamese databases hebrew news www deskutils irc packages x11 Not that it would, of course, since this is rather too flat of a hierarchy and I'm sure someone could do better with even 10 minutes thought (I just yanked in an `ls -C /usr/ports/[a-z]* and added "system" :-) Into each of these directories could go all the metadata which describes the contents at that level of the tree. Ultimately you get to the leaf nodes and those contain the metadata necessary for describing that package - where its source lives, how to build and install it, its dependencies, whether the sources can go away again after its built and installed, etc. etc. All of this kind of information is ultimately pretty package-agnostic and I can easily see a tree from which I could say "make packages FORMAT=deb" or "make packages FORMAT=bsd" with equal ease, not to mention building the "operating system bits" themselves. If one choses and represents the metadata correctly, it's always a superset of the information needed by any particular target package format. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 15:43:20 2001 Delivered-To: freebsd-libh@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 9592337B71E for ; Thu, 29 Mar 2001 15:43:18 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2TNh4g84533; Thu, 29 Mar 2001 15:43:05 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: mwm@mired.org Cc: chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <15043.49939.888504.953014@guru.mired.org> References: <20010329140754K.jkh@osd.bsdi.com> <15043.49939.888504.953014@guru.mired.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010329154304B.jkh@osd.bsdi.com> Date: Thu, 29 Mar 2001 15:43:04 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 4 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My mistake! I had forgotten all about this page. It's a bit buried. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 17:58:45 2001 Delivered-To: freebsd-libh@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-50.dsl.lsan03.pacbell.net [63.207.60.50]) by hub.freebsd.org (Postfix) with ESMTP id 5C3C737B71B for ; Thu, 29 Mar 2001 17:58:42 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C2C9166D82; Thu, 29 Mar 2001 17:58:41 -0800 (PST) Date: Thu, 29 Mar 2001 17:58:41 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages Message-ID: <20010329175841.A9440@xor.obsecurity.org> References: <20010329132249.A6943@xor.obsecurity.org> <20010329140754K.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010329140754K.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Thu, Mar 29, 2001 at 02:07:54PM -0800 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2001 at 02:07:54PM -0800, Jordan Hubbard wrote: > > Does the PackageNG have a webpage? And, any idea how far along they are > > in their progress? >=20 > It's not that well organized. :) Like I said, consider it more of a > pure research project for now. Yep, I just wanted to make sure people from both sides keep the other in mind, and don't do too much in the way of duplicating effort. Kris --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6w+hRWry0BWjoQKURAi9NAKD2xry5oo14KCfgoMIGuZvft/1DBgCfUiI0 pO8qy6dB3lbAZSEHYDYM/m8= =GW/s -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Thu Mar 29 20:58:34 2001 Delivered-To: freebsd-libh@freebsd.org Received: from schutzenberger.liafa.jussieu.fr (schutzenberger.liafa.jussieu.fr [132.227.81.123]) by hub.freebsd.org (Postfix) with ESMTP id 5202B37B719 for ; Thu, 29 Mar 2001 20:58:32 -0800 (PST) (envelope-from espie@schutzenberger.liafa.jussieu.fr) Received: (from espie@localhost) by schutzenberger.liafa.jussieu.fr (8.10.1/8.10.1) id f2U4wHB28126; Fri, 30 Mar 2001 06:58:17 +0200 (CEST) Date: Fri, 30 Mar 2001 06:58:17 +0200 From: Marc Espie To: Jordan Hubbard Cc: brooks@one-eyed-alien.net, chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages Message-ID: <20010330065817.A30197@schutzenberger.liafa.jussieu.fr> Reply-To: Marc.Espie@liafa.jussieu.fr References: <20010329142742L.jkh@osd.bsdi.com> <20010329144334.A9413@Odin.AC.HMC.Edu> <20010329152056I.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010329152056I.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Thu, Mar 29, 2001 at 03:20:56PM -0800 Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 29, 2001 at 03:20:56PM -0800, Jordan Hubbard wrote: > Not that it would, of course, since this is rather too flat of a > hierarchy and I'm sure someone could do better with even 10 minutes > thought (I just yanked in an `ls -C /usr/ports/[a-z]* and added "system" :-) In OpenBSD, we now have: - non flat hierarchies (indeed, our ports tree is three level deep) - targets to cross-reference categories (by creating links around). - extra-checks for dependencies (so that you don't end up depending on a link. - a `search' framework at the bsd.port.subdir.mk level You could call that meta tools to handle taxonomy, though the meta still needs to become more abstract :) e.g., if you define a specific variable (say, search=, or cat=), then it builds a list of SUBDIRS, and uses that directly to build stuff in subtrees (of course this can only be efficient with a central index file that is updated from time to time). This can also be used to reorder a list of ports to build: you have a list of ports, you create a list of directory/dependency for tsort, and then use tsort to get a `correct' list of SUBDIRS that will never backtrack. Some recent changes were geared into that direction: - framework to `generalize' subdirs and add options (flavors) there: SUBDIR= dir,flavor does work. - a new tsort that provides `stable' tsort, optionally, by using a heap to yield a topological order that is not too different from the input's order if at all possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Fri Mar 30 8: 8:12 2001 Delivered-To: freebsd-libh@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id E688537B71A for ; Fri, 30 Mar 2001 08:07:12 -0800 (PST) (envelope-from alex@cichlids.cichlids.com) Received: from fwd02.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14j1QW-0006FO-01; Fri, 30 Mar 2001 18:07:04 +0200 Received: from neutron.cichlids.com (520050424122-0001@[62.158.38.143]) by fmrl02.sul.t-online.com with esmtp id 14j1QD-1MI2U4C; Fri, 30 Mar 2001 18:06:45 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 7F0F6AB44; Fri, 30 Mar 2001 18:09:00 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BE33E14BBE; Fri, 30 Mar 2001 17:06:41 +0200 (CEST) Date: Fri, 30 Mar 2001 17:06:41 +0200 From: Alexander Langer To: Mike Meyer Cc: Jordan Hubbard , chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages Message-ID: <20010330170641.B10197@cichlids.cichlids.com> References: <20010329132249.A6943@xor.obsecurity.org> <20010329140754K.jkh@osd.bsdi.com> <15043.49939.888504.953014@guru.mired.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15043.49939.888504.953014@guru.mired.org>; from mwm@mired.org on Thu, Mar 29, 2001 at 05:19:47PM -0600 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thus spake Mike Meyer (mwm@mired.org): > The libh project has a home page - and you even wrote most of > it. Isn't that what PackageNG is, for now? Oh, I didn't know that PackageNG == libh. Hehe. Well, I've been subscribed to this mailinglist and don't see a problem with libh and OP. If the OP stuff is provided as a library part, it can easily be merged into libh. On the other hand, OP developers might want to read the design + feature document of libh's package system which I'd like to have _completely_ supported, if not even in an extended way. I'm attaching it now. Alex -- cat: /home/alex/.sig: No such file or directory --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sysinstall2.txt" -*- Mode: Text; Mode: Auto-Fill; Mode: Flyspell -*- ====================================================================== . Security ====================================================================== All procs described in the API and Database sections are to be provided for the master interpreter. For getting information, installation, undoing, uninstallation of each package (including referenced packages and packages being (un)installed during installation of another package to solve feature requirements and conflicts problems) slave safe interpreter is to be created and all procs described in the API and Database sections (if not explicitly stated) are to be aliased in the slave interpreter with same names (including namespaces) using System::create_safe_interpreter. Procs supplied with a package file (e.g. description, provides, install etc.) are to be executed by safe slave interpreter only. Safe slave interpreter is to be created just before execution of these procs and destroyed immediately after execution. All procs executed by the master interpreter and modifying files on filesystems (e.g. PackageStream::File::write, PackageStream::File::patch) should check if files being modified or created is under path allowed to modify by the user. If file is under the path forbidden to modify by the user exception is to be raised. Note pathname passed to these procs may contain symbolic links and in this case all pathnames (original one and with resolved symbolic links one by one) are to be checked for access restrictions. ====================================================================== . Package stream opening ====================================================================== Package file is opened using Archive::open, then package object is created using PackageStream::open. ====================================================================== . Information about package ====================================================================== Information about package (description, features etc.) could be obtained using corresponding methods of Package object. ====================================================================== . Features lists ====================================================================== Feature is a name (no spaces) with optional feature version specification. Feature version specification: regular version, serial number (integer), snapshot date (time_t GMT). Accessors to the feature type are in the Feature namespace. Each package contains proc returning list of features provided and three procs to check if features provided by the current system meet package requirements (see Package file structure). Checking functions may return list of features not met or conflicting by the current system. If a package contains platform dependent binaries it should require special platform feature. ====================================================================== . Main package and subpackages ====================================================================== Each package contains files which are to be installed during package installation. Package also may contain subpackages which may be optionally installed. Subpackages have no their own installation prefixes (they use main package installation prefix), subpackages provide no features of their own and therefore may not install files affecting features provided by the main package. Subpackage has no subpackages. User may choose to install or not to install each subpackage along with the main package. Subpackages are not recorded in the database as a separate structure, if subpackage has been installed it's files are owned by the main package and will be uninstalled during main package uninstallation. A good example of what to be put into subpackage are manual pages and documentation which user may omit for installation to save disk space. ====================================================================== . SYSTEM package ====================================================================== There is a package called SYSTEM which cannot be removed. It owns no files. Records corresponding to this package are inserted into the database during it's creation (Database::create). SYSTEM package provides the following features: i386 version 3.0 serial 386 for i386 based systems i386 version 4.0 serial 486 for i586 based systems i386 version 5.0 serial 586 for Pentium based systems i386 version 6.0 serial 686 for PentiumPro and PentiumII based systems `uname -s` version `uname -r` In case of hardware upgrade/downgrade Database::hardware_upgrade could be called to update SYSTEM package records and check all the packages for fitness into this hardware upgrade. intel-mmx ====================================================================== . Installation ====================================================================== Installation of a package is done by calling in safe interpreter install proc supplied with the package. This proc is to be first sourced into special package namespace (PackageStream::name_space) by calling PackageStream::source. proc install is called with three arguments: database handle, package_stream handle and newly created package handle. In case of install abnormal termination (e.g. exception is raised) (partially) installed package will be uninstalled (undone). Default proc install generated automatically by the package creation program does the following: 1. Checks if the current system meets requirements by calling check_requirements check_conflicts check_users_groups_requirements check_suggestions If any of these calls return non-empty list it calls Callback::package_requirements_not_met. (It actually calls this callback in any case and if all lists are empty callback returns "ignore"). If callback returns empty string this step is repeated. If callback returns string "ignore" problems met at this step are ignored and installation moves to step 2. If callback returns another non-empty string exception is raised, string is supposed to contain some informative message, e.g. "User canceled installation". check_requirements, check_conflicts, and check_suggestions return lists which are to be explicitely deleted by proc install. 2. Checks if features provided by the package with the same versions are already present in the system. If yes it calls Callback::installation_over_installed passing package_stream. If callback returns an empty string this step is repeated. If callback returns non-empty string exception is raised, string is supposed to contain some informative message. 3. Checks if there are packages installed in the system conflicting with the features being installed (Database::packages_conflicting, Package::could_be_installed) If yes it calls Callback::reverse_conflict. If callback returns an empty string this step is repeated. If callback returns non-empty string exception is raised, string is supposed to contain some informative message. 4. Creates package record in the database (Database::new_package) and fills directory_prefix, features and features checking procs code, description fields. 5. Installs each non-sysinstall specific file supplied with the main package and directories leading to this file. a. If directories leading to a file being installed are not present they are created. b. Checks if file is already present. c. Checks what packages own original file using Database::packages_owning d. Replaces (patches) or not original file depending on PackageStream::File::replacement_scheme using PackageStream::install_file or PackageStream::patch_file If saving undo information is requested (Configuration::save_undo) stores undo file (Undo::File::store_file_or_patch) or patch in the undo staging area (see Undo section), adds record into undo structure associated with the package being installed. e. Inserts in the database record corresponding for the file installed or patched (value returned by PackageStream::install_file or PackageStream::patch_file) f. Inserts in the database records corresponding for each directory (except root) leading to files being owned by the package. 6. If package contains subpackages calls Callback::install_subpackages passing list of subpackages. Callback should return list of subpackages to be installed or empty list to avoid subpackages installation. Installs each file of each subpackage chosen for installation using the same rules as for files of the main package. 7. If package contains references to other packages to be installed install calls PackageStream::install_references. If any of references cannot be installed (package file cannot be found or insolvable problems during installation or user aborted installation) the main package installation is undone. 8. Inserts in the database undo (undo script is automatically generated, see Undo section) and uninstall records for the package. ====================================================================== . Upgrade ====================================================================== Upgrade is an installation of a new package followed by uninstallation of all packages providing the same features as the new package but of different versions (it could be upgrade or downgrade). Upgrade of a package is done by calling in safe interpreter upgrade proc supplied with the package. This proc is to be first sourced into special package namespace (PackageStream::name_space) by calling PackageStream::source. Default proc upgrade generated automatically by the package creation just calls proc install supplied with the package. Uninstallation of upgraded packages is done by package handling library upon successful completion of proc upgrade (Note calling any package uninstall is forbidden for scripts supplied in the package file for security reasons). ====================================================================== . Uninstallation ====================================================================== Uninstallation is done by creating safe interpreter and calling proc uninstall supplied with a package file and stored in the database. These actions are done by the Package::uninstall proc. Automatically generated (by package creator) uninstall proc does the following: 1. Gets list of packages requiring features provided by the package being uninstalled (Database::packages_requiring). For each package returned calls Package::could_be_uninstalled, if any of Package::could_be_uninstalled calls return zero uninstallation is aborted by raising an exception with informative message (e.g. list of packages still requiring package being uninstalled). 2. For each file owned by the package being uninstalled: a) If file does not exist calls Callback::owned_file_does_not_exist_for_uninstall and if this callback returns non-empty string raises an exception. b) If file exists and owned by other packages file is removed or left using rules described in the Files ownership section. 3. Remove each directory owned by the package if it is not owned by other packages. If a directory is not owned by other packages and it is not empty calls Callback::uninstall_non_empty_dir (callback may remove this directory) 4. Erases undo record (Database::package_undo_erase) 5. Erases package record (Database::remove) ====================================================================== . Undo ====================================================================== Undo files staging area is directory where undo files are stored. Unique names for files to store in this area are generated by Undo::unique_pathname. Undo staging area path is stored in the Configuration table with "undo_staging_area" key. Undo script is automatically generated and stored in the database (Database::package_undo_store). It does the following: 1. Gets list of packages requiring features provided by the package being uninstalled (Database::packages_requiring). For each package returned calls Package::could_be_uninstalled, if any of Package::could_be_uninstalled calls return zero uninstallation is aborted by raising an exception with informative message (e.g. list of packages still requiring package being uninstalled). 2. For each file reference stored in the undo database: Check if file with original pathname exists. a) If it does not exist put saved file (if saved is patch, raise an exception), find packages owning file put and update their records. b) If file exists find other packages owning this file. If package being undone is the latest (by installation time) replace or patch original file and update records of other packages owning this file. c) If file exists and package being undone is not the latest (by installation time) original file left untouched. 3. Remove each directory owned by the package if it is not owned by other packages. If a directory is not owned by other packages and it is not empty calls Callback::undo_non_empty_dir (callback may remove this directory) 4. Erases undo record (Database::package_undo_erase) 5. Erases package record (Database::remove) ====================================================================== . Package installation consistency checking ====================================================================== This check is done by calling Package::consistency_check. The proc returns list of problems encountered. Each problem is list of package_file and list of list of three elements: string describing problem, e.g. "md5", "absent", old value, new value. This proc checks each file owned by the package for having recorded attributes (length check for directories is not performed). ====================================================================== API to be aliased in a safe slave interpreter ====================================================================== API procs are defined in a master interpreter and aliases for all of them (if not explicitly stated) are defined in a safe slave interpreter where all procs supplied with the package are to be executed. Types ----- Instance of type could be either list or number or string. It cannot be an associative array because it cannot be returned from proc. List with type name specified as one of elements is preferable to allow at least some type checking. Types should have special value called NULL and a proc checking if value of a handle is NULL. feature - contains all information about feature including feature name, version, serial, snapshot date. package_stream - handle by which information from stream corresponding to package file could be read. It could cache the information already read. Procs from the PackageStream namespace deal with package stream and expects handle as first argument. package_description package_structure - contains all information about package structure including default directory_prefix for installation, list of files to be installed, list of references to other packages to be installed along with this package. See PackageStructure. subpackage package_stream_file package_reference - reference to packages located somewhere package - handle by which all information about package stored in the database could be read. Procs from the Package namespace deal with package stream and expects handle as first argument. package_file file - info about files owned by a package including pathname (relative), user, group, permission, symbolic link contents, MD5 etc. undo - info for undoing package installation undo_file - info of original file (or patch) stored package_creator - handle stream - input or output stream (but not both) containing directory and package data, each data chunk is separately compressed (using libzip). Stream has random access to data chunks, i.e. if underlying stream access structure (e.g. ftp without reget) does not allow random access the whole stream is to be cached somewhere in the local filesystem and provide random access. . Feature ------- proc Feature::new {name version {serial 0} {snapshot 0}} Creates and returns new feature $Feature name Returns the feature name. $Feature version Returns version. $Feature serial $Feature snapshot $Feature compare another_feature Returns -1, 0, 1 depending on feature version comparisons. $Feature check_integrity Returns non-zero if value specified is not of type feature . PackageStream ------------- Procs to read information from package_stream handle. proc PackageStream stream Returns package_stream opened for reading from stream. Generates unique name for package_namespace where all scripts provided with the package file are to be sourced. $package_stream name_space Returns name of namespace where all procs supplied with the package file are to be sourced. $package_stream name Returns package_name. Sources the SYSINSTALL/description.tcl script if not sourced yet and then calls package_namespace::name $package_stream description Returns package_description. Sources the SYSINSTALL/description.tcl script if not sourced yet and then calls package_namespace::description $package_stream features Returns list of features provided by the package. Sources the SYSINSTALL/features.tcl script if not sourced yet and then calls package_namespace::provides $package_stream requires Returns list of required features for the package. Sources the SYSINSTALL/features.tcl script if not sourced yet and then calls package_namespace::provides $package_stream could_be_uninstalled_proc Returns string with proc code. Sources the SYSINSTALL/features.tcl script if not sourced yet and then calls package_namespace::provides $package_stream conflicts Returns list of conflicting features for the package. Sources the SYSINSTALL/features.tcl script if not sourced yet and then calls package_namespace::provides $package_stream could_be_installed_proc Returns string with proc code. Sources the SYSINSTALL/features.tcl script if not sourced yet and then calls package_namespace::provides $package_stream structure Returns package_structure. Sources the SYSINSTALL/structure.tcl script if not sourced yet and then calls package_namespace::structure $package_stream source Sources all not yet sourced scripts supplied with the package file. $package_stream install Calls proc install supplied with package in the safe interpreter. $package_stream upgrade Calls proc upgrade supplied with package in the safe interpreter. $package_stream prefix Returns installation prefix based on configuration. $package_stream install_file package_stream_file Installs the file attached to the package. Returns package_file with all attributes properly filled. If file already exists it is replaced. (Uses PackageStream::File::write) [If Configuration::no_action returns non-zero does not install file and does not change file ownership for other packages just reports what is to be done. If file is to be installed under the path for which access is forbidden by the configuration (see the Security section) exception is raised.] $package_stream patch_file package_stream_file Patches original file using the patch attached to the package. Returns package_file with all attributes properly filled. If original file does not exist raises an exception. (Uses PackageStream::File::patch) [If Configuration::no_action returns non-zero does not patch file and does not change file ownership for other packages just reports what is to be done. If file to be patched is under the path for which access is forbidden by the configuration (see the Security section) exception is raised.] $package_stream append_file package_stream_file {create ""} Appends to the original file using the data attached to the package. Returns package_file with all attributes properly filled. If original file does not exist and "create" is not specified as last argumen raises an exception. (Uses PackageStream::File::patch) [If Configuration::no_action returns non-zero does not patch file and does not change file ownership for other packages just reports what is to be done. If file to be patched is under the path for which access is forbidden by the configuration (see the Security section) exception is raised.] $package_stream create_symlink package_stream_file $package_stream create_device package_stream_file $package_stream create_hardlink package_stream_file $package_stream install_references Installs each reference containing in the package using a separate stream. $package_stream file_exists package_stream_file Returns if file corresponding to package_stream_file exists $package_stream file_pathname_for_installation package_stream_file Returns pathname for installation of package_stream_file . PackageStream::Structure ---------------- proc PackageStructure {prefix package_stream_file_list subpackage_list package_stream_reference_list} To be used in SYSINSTALL/structure.tcl Returns package_structure $PackageStream::Structure default_prefix Returns installation directory prefix recorded in the package file. Note raises an exception if called for subpackages. $PackageStream::Structure files Returns list of package_stream_file, files are to be affected by the installation of the package. $PackageStream::Structure has_subpackages Returns number of subpackages the main package has. $PackageStream::Structure subpackages Returns list of subpackage for each subpackage. $PackageStream::Structure has_references Returns number of references the package has. $PackageStream::Structure references Returns list of package_stream_reference to other packages containing in this package. $PackageStream::Structure check_integrity Returns non-zero if package_structure has invalid type or value . PackageStream::Subpackage ---------- proc PackageStream::Subpackage {name description package_stream_file_list} $PackageStream::Subpackage name $PackageStream::Subpackage description Returns string describing subpackage. $PackageStream::Subpackage files Returns list of package_stream_file, files are to be affected by the installation of the subpackage. . PackageStream::File ------------------- proc PackageStream::File {file_arguments_list attachment {replacement ""} {hardlink ""}} file_arguments_list is list of arguments for File command. $PackageStream::File attached {package_stream_file} Returns an empty string if file is not attached but will be generated by installation (e.g. symbolic link, device). Returns string "file" if file is attached and is to be put as is. Returns string "patch" if patch is attached and is to be applied to already existing file. $PackageStream::File replacement_scheme {package_stream_file} Returns an empty string if default replacement scheme (described in section Files ownership) is to be used. Returns string "always_replace" if old file (if exists) is to be saved and attached file is to be put instead (see section Files ownership for description of ownership transitions). Returns string "never_replace" to put file only if it does not already exists (see section Files ownership for description of ownership transitions). $PackageStream::File See File. . PackageStream::Reference ------------------------ proc PackageStream::Reference {url} $PackageStream::Reference url Returns URL pointing to the package. . Package ------- package is a handle to retrieve and store package data in the database. If Configuration::no_action returns non-zero the following procs do not actually change the database, just report what is to be done. Package handle is returned by Database new_package, package, packages_*. $package name {new_name ""} Returns or sets (and returns old) package name. $package installation_time {new_installation_time ""} Returns or sets (and returns old) package installation time (time_t). $package features {features_list {}} Returns or sets list of features provided by the package. Features returned must be deleted or use [delete_objects "Feature"] $package requires {requirements_list {}} Returns or sets list of features required by the package. Features returned must be deleted or use [delete_objects "Feature"] $package conflicts {conflicts_list {}} Returns or sets list of conflicting features for the package. Features returned must be deleted or use [delete_objects "Feature"] $package could_be_uninstalled {database package feature_list} Creates safe slave interpreter aliasing all the functions of this API, then sources by this safe slave interpreter and calls proc supplied with package to check if the specified feature could be uninstalled from the system without damaging this package installation. Returns non-zero if feature could be uninstalled and zero otherwise. $package could_be_uninstalled_proc proc_code Stores proc to check required features versions. $package could_be_installed {database package feature} Creates safe slave interpreter aliasing all the functions of this API, then sources by this safe slave interpreter and calls proc supplied with package to check if the specified feature could be installed onto the system without damaging this package installation.. Returns non-zero if feature could be installed and zero otherwise. $package could_be_installed_proc proc_code Stores proc to check conflicting features versions. $package description {new_description {}} Returns or sets package_description. Description must be deleted in both cases (after setting and returning) or use [delete_objects "Package_Description"] $package files Returns list of package_file owned by the package. Files returned must be deleted or use [delete_objects "Package_File"] $package disown pathname Remove ownership for the specified file from package by removing record associated with the file. $package own pathname Adds ownership for the specified file to package by adding record associated with the file. $package owns package file_pathname ????inode Returns package_file if specified file is owned by the package and NULL otherwise. File returned must be deleted or use [delete_objects "Package_File"] $package undo Creates safe slave interpreter aliasing all the functions of this API, then undoes installation of the package using this interpreter. (see Undo section) If Configuration::no_action returns non-zero does not do anything just reports what is to be done. $package uninstall Creates safe slave interpreter aliasing all the functions of this API, then uninstalls package using this interpreter.. (see Uninstall section) If Configuration::no_action returns non-zero does not do anything just reports what is to be done. $package consistency_check See the Consistency checking section. $package remove Removes from the database all information regarding package. If Configuration::no_action returns non-zero does not do anything just reports what is to be done. $package exists Returns if this package records are still exist in the database $package has_undo_info Returns if undo info is saved for the package. $package has_uninstall_proc Returns if proc uninstall is saved for the package. . Package::Description ---------------- proc Package::Description {summary description author {canonical_name ""} {references {}}} $Package::Description summary $Package::Description description $Package::Description author $Package::Description canonical_name Returns string (Packages will often contain third-party software with completely different naming conventions.) $Package::Description references Returns list of references to this package. Returned references must NOT be deleted using neither delete nor delete_objects $Package::Description check_integrity Returns non-zero if value specified is not of type package_description . Package::File ------------- proc Package::File {file {{filesystem inode} {}} } $package_file check directory_prefix Check if file attributes recorded match the file on filesystem, returns list of not matched attributes or empty list. $package_file inode {{filesystem inode} {}} Returns or sets list of filesystem and inode . File ---- proc File {pathname length mtime user group permissions {symlink ""} {{major minor} {}}} returns file object $File pathname {file {new_pathname ""}} $File length {file {new_length ""}} $file md5 {new_md5 ""} $File mtime {file {new_mtime ""}} - time of last modification $File user {file {new_user ""}} $File group {file {new_group ""}} $File permissions {file {new_permissions ""}} - octal code that chmod(1) uses $File symlink {file {new_symlink ""}} - symlink content $File device {file {{major minor} {}} - returns list of major and minor . Undo ---- proc Undo::new {undo_file_list {undo_script ""}} proc Undo::files {undo} Returns list of undo_file associated with undo information proc Undo::script {undo} Returns script associated with undo information . Undo::File ---------- proc Undo::File::new {file saved_pathname type {compression ""}} proc Undo::File::store_file_or_patch {file_or_patch_pathname type} Stores original file or patch (possibly compressed) in the staging area and returns undo_file (uses Undo::unique_pathname). proc Undo::File::file {undo_file} Returns file (describing pathname, permissions etc.) See File namespace. proc Undo::File::saved_pathname {undo_file {new_saved_pathname {}}} Returns or sets pathname of saved file proc Undo::File::type {undo_file {new_type ""}} Returns or sets type of undo file ("file", "patch", "reverse_patch") proc Undo::File::compression {undo_file {new_compression {}}} Returns or sets type of compression of undo file ("", "gzip", "bzip2") . PackageCreator -------------- proc PackageCreator::create_package {package_name package_dir package_files_dir {ignore {CVS RCS *~ *.bak}}} Creates new package file specified by package_name with .zip suffix and put it into package_dir (if this file exists exception is raised) using files from package_files_dir. Files and directories from the ignore list (may be shell patterns) will not be placed into package. package_files_dir may contain SYSINSTALL dir with scripts to be included into package. All necessary scripts and procs (if not provided by package creator in the SYSINSTALL dir) will be generated automatically. (See the Package creation section). proc PackageCreator::generate_procs {package_name package_files_dir {ignore {CVS *~}}} Generates scripts to be supplied with the package and put them into SYSINSTALL dir. Old files (if present) are renamed. This could be used to start creating package with modified procs. proc PackageCreator::create {stream} Returns package_creator opened for writing into stream. proc PackageCreator::close {package_creator} Adds sysinstall specific attributes to the archive. Closes stream. . System ------ proc System::md5 {pathname} - evaluates md5 of the file specified proc System::break_time_t {time_t} Returns list consisting of broken local time_t value: year (e.g. 1998), month-name (e.g. January), day-of-month (1..31), hour (0..23), minute (0..59), second (0..59), week-day (e.g. Sunday), year-day (0..365) proc System::string_time_t {time_t} Returns result of ctime() but without trailing newline. . Configuration ------------- Only procs for getting configuration parameters are aliased for the slave interpreter where procs supplied with the package are to be called. No procs for setting configuration parameters are to be aliased for the safe slave interpreter. proc Configuration::save_undo Returns non-zero if saving undo information is requested by the user. proc Configuration::no_action Returns non-zero if no action should be actually done, just report what is done (filesystems and database are not changed). proc Configuration::path_to_patch Returns path to patch program . Stream ------ proc Stream::open {url} Opens stream for reading. Makes sure this is a package data. Returns stream. proc Stream::close {stream} proc Stream::directory {stream} Returns list of files in the stream proc Stream::create {pathname} Creates new stream with specified pathname, if file already exists exception is raised. Returns stream. . Callback -------- These callbacks are provided by the library with default actions and supposed to be overridden in the real installation program. To override a callback you need to create a command in the namespace Callback with the name of the callback followed by suffix `_master' and having first argument interpreter_name, e.g. to override Callback::package_requirements_not_met you should write: proc Callback::package_requirements_not_met_master {interpreter database package_stream requirements conflicts users_groups suggestions} { callback code } proc Callback::package_requirements_not_met {database package_stream requirements conflicts users_groups suggestions} Called by install if any of requirements are not met in the current system. Arguments are lists returned by check_* procs from package namespace. The callback should try to solve problems and returns an empty string to continue installation and check for meeting requirements again, string "ignore" to continue installation without checking the requirements, other non-empty string to abort installation (this string supposed to contain some informative message, e.g. "User canceled installation".). Note callback may be called with all empty lists, in this case it should consider no problems and return "ignore". Default action for this callback is to return string "package_requirements_not_met: default action is abort" if either requirements, conflicts or users_groups lists are not empty. proc Callback::installation_over_installed {database package_stream duplicated_features_list} Called by install if features provided by the package with the same versions are already present in the system. If this is really installation over installed of the same package and user wants it to produce all information about previous package installation is to be erased from the database. If other packages provide the same feature with the same version installation cannot continue until these packages are uninstalled. Callback should return an empty string to try to continue installation by repeating feature duplication check or non-empty string (better with informative message) to abort installation. Default action for this callback to check if it is installation over installed of the same package and uninstall previous package installation and return empty string in this case or return string naming packages providing the same features as provided by the package being installed. proc Callback::file_to_be_installed_exists_and_owned_by_other_packages {database package_stream package_stream_file owners} Called by install if file to be installed exists and owned by other packages. Should return an empty string to overwrite file or error message to abort installation. Default behavior is to check if owners of the file provide the same features as package being installed and allow file overwriting in this case. If file is owned by unrelated package error message is returned. proc Callback::reverse_conflict {database package_stream conflicting_packages_list} Called by install if there are packages already installed in the system listing the package being installed in their conflicts lists. Should return en empty string to try to continue installation by repeating reverse conflict check or non-empty string (better with informative message) to abort installation. Default actions is to return string "reverse_conflict: abort". proc Callback::directory_write_access {database package_stream directory} Called if during installation/deinstallation write access to the specified directory is requested. Should return an empty list if access is granted or list of two strings: action ("abort") and error message for user if access is not granted. Default action is to check if access is forbidden by the configuration. proc Callback::file_overwrite {database package_stream filename} Called if during installation/deinstallation existing file is going to be completely overwritten. Should return an empty list if access is granted or list of two strings: action ("abort") and error message for user if access is not granted. Default action is to return an empty list. proc Callback::file_append {database package_stream filename} Called if during installation/deinstallation some data is going to be appended to an existing file. Should return an empty list if access is granted or list of two strings: action ("abort") and error message for user if access is not granted. Default action is to return an empty list. proc Callback::file_patch {database package_stream filename} Called if during installation/deinstallation existing file is going to be patched. Should return an empty list if access is granted or list of two strings: action ("abort") and error message for user if access is not granted. Default action is to return an empty list. proc Callback::install_subpackages {package_structure} Called by install if main package contains subpackages and expected to return list of subpackages user chosen to install. Default action is return complete list of subpackages of the specified package, i.e. install all subpackages. proc Callback::owned_file_does_not_exist_for_uninstall {package package_file} Called by uninstall if file owned by the package specified does not exist. Should return an empty string to ignore the problem or message to abort uninstallation. Default action is to return an empty string. proc Callback::uninstall_non_empty_dir {package pathname} Called by uninstall if directory is not owned by other packages and not empty. Callback may remove the directory. Value returned by this callback is ignored. Default action is do nothing. proc Callback::undo_non_empty_dir {package pathname} Called by undo if directory is not owned by other packages and not empty. Callback may remove the directory. Value returned by this callback is ignored. Default action is do nothing. proc Callback::install_upgrade {database url} Called if during package installation/upgrade required features are not provided by the system but package specified (url) found to be provided necessary feature(s). Callback should return "install" to install the package, "upgrade" to install the package using upgrade, an empty string to not to install the package, any other string to abort main package installation with the error message made of this string. Default action is to return "install". proc Callback::uninstall_required_features_master {database toUninstall requirers} Called during package uninstallation if (some) features provided by the package being uninstalled are required by other packages currently installed on the system and no other packages provide suitable features. Should return an empty string to continue (force) uninstallation or error message to cancel uninstallation. proc Callback::exec_wanted {command} Called if during package installation/upgrade/uninstallation execution of external command via system() is requested. Should return actual command to be executed or an empty string to omit execution and returning status 0. Default action is to return string passed as parameter. proc Callback::register {callback_name command} Registers tcl command as callback to be called. Callback name is taken from above list of callbacks (without Callbacks:: prefix). Upon call necessary arguments are appended to the command list. proc Callback::unregister {callback_name} Unregisters callback registered by the Callback::register . Exec ---- proc exec {args} Concatenate args and execute them via system(). Note user will be asked if she wants this command to be executed and she can modify the command before execution. Returns command status. . DirectoriesAccess proc DirectoriesAccess { [dirs_list]} Sets or gets directories access allow or deny list proc DirectoriesAccess {save database} Saves directories access lists into the database ====================================================================== . API NOT to be aliased in a safe slave interpreter ====================================================================== proc Configuration::save_undo new_save_undo Sets save_undo flag to either zero if saving undo information is not necessary or non-zero otherwise. proc Configuration::no_action new_no_action Sets no_action flag to either zero to make all actions changing either database or filesystem actually done or non-zero otherwise. proc Configuration::path_to_patch new_path_to_patch Sets path to patch program proc Undo::unique_pathname Returns unique filename in the undo staging area to store new file (undo staging area path is stored in the Configuration table with "undo_staging_area" key, Database::configuration). ====================================================================== Database ====================================================================== . Database Tables =============== Table Packages Package_Id id key, unique, not null unique package identifier Name string key, not null InstallationTime time_t not null Table Features Package_Id id key, not null multiple records for the same package for each feature Type string key, not null "provide", "require", "conflict" Name string key, not null feature name Version string key, not null Serial integer Snapshot time_t Table Scripts Package_Id id key, not null multiple records for the same package Type string key, not null "could_be_installed" Data string not null script itself Table Descriptions Package_Id id key, unique, not null Summary string Description string Author string Canonical_name string Table References Package_Id id key, not null multiple records for the same package Reference string not null reference to the package Table Files Package_Id id key, not null multiple records for the same package for each file owned MD5 string FileInfo_Id id key, not null key to FileInfo table Table FileInfo Pathname string key, not null Filesystem string key, not null Inode string key, not null Length string not null Mtime time_t not null User string not null owner of the file Group string not null Permissions string not null octal code that chmod(1) uses Symlink string symbolic link content Major string for devices Minor string for devices Table Undo Package_Id id key, unique, not null Script string not null Table FilesUndo Package_Id id key, not null multiple records for the same package for each file owned SavedPathname string key, not null pathname where file is saved Type string not null "file", "patch", "reverse_patch" (patch -R to be applied) Compression string "" (no compression), "gzip", "bzip2" FileInfo_Id id key, not null key to FileInfo table Table Configuration Key string key, not null Value string . Database API aliased in a safe slave interpreter ============ Types ----- database_handle Functions --------- proc Database::open {{basedir /var/sysinstall}} Opens and locks database at the optionally specified location. Returns database handle. If program ever existed without calling Database::close lock should be released anyway. If database is already locked raises an exception. Should check database consistency. $database close Closes database, releases lock. $database feature feature_name Returns list of features matching feature_name. If there are no installed features matching the specified name returns empty list. Features returned must be deleted or use [delete_objects "Feature"] $database feature_other_versions feature Returns list of features with the same name as specified feature but of other versions or an empty list. Features returned must be deleted or use [delete_objects "Feature"] $database package {database_handle feature} Returns package providing the specified feature. If there is no package providing the feature returns NULL. $database packages_by_name package_name Returns list of packages with the specified name. $database all_packages Returns list of all packages installed. $database packages_owning file_pathname ????inode Returns list of packages owning the specified file. $database packages_requiring feature_list Returns list of packages requiring at least one of the specified features. Versions of the features are ignored. $database packages_conflicting feature Returns list of packages conflicting the specified feature. Version of the feature is ignored. $database package_undo package Returns undo (or NULL) for the specified package. $database package_undo_store package undo Stores undo for the specified package. $database package_undo_erase package Erases undo for the specified package from the database. $database new_package Returns new package handle to store in the database. If Configuration::no_action returns non-zero does not do anything just reports what is to be done and returns dummy package handle. proc Database::create {{basedir /var/sysinstall}} Creates initial database, directory should be empty. Inserts records corresponding to the SYSTEM package. If Configuration::no_action returns non-zero does not do anything just reports what is to be done. proc Database::repair {{basedir /var/sysinstall}} Tries to repair (with possible user interaction) corrupted database. If Configuration::no_action returns non-zero does not do anything just reports what is to be done. $database hardware_upgrade Updates records of the SYSTEM package and checks _all_ the packages for fitness into new hardware system. Returns list of package having conflicts with the SYSTEM package. If Configuration::no_action returns an emtpy list does not do anything just reports what is to be done. $database check_conflicts Returns list of package having problems, e.g. requiring features not provided by the system, conflicting features provided by the system. $database check_features_duplicates Returns list of features provided multiple times (different versions). $database configuration key {value {}} Retrieves or stores configuration table record. $database sync $database flush Synchronizes database with disk ====================================================================== . Package file structure ====================================================================== Package file is a regular zip archive which could be created, extracted and probably modified by libzip. Archive should contain directory at the beginning. Integrity of the data is managed by libzip. Attributes supplied with zip archive: Attribute key Required Attribute value -------------- -------- ----------------------------------- Type Yes sysinstall package 2.0 Version Yes 1.0 Files supplied with zip archive (order of files is mandatory): "SYSINSTALL/description.tcl" (required) Should call `name', `summary', `description', `author' to set corresponding values. Each proc accepts one argument of type string. "SYSINSTALL/features.tcl" (required) Provides: proc provides {} Returns list of features provided by the package, list should be the same as contained in the package structure below. proc requires {} Returns list of features required by this package. proc check_requirements {database_handle} Returns list of requirements not met in the current system. proc conflicts {} Returns list of features conflicting with the package. proc check_conflicts {database_handle} Returns list of conflicts met in the current system. proc could_be_installed_proc {} Returns string with the code of proc. See Package::could_be_installed. proc could_be_uninstalled_proc {} Returns string with the code of proc. See Package::could_be_uninstalled. proc check_users_groups_requirements {} Returns list of two elements: list of users and list of groups required by this package installation but not met in the current system. proc check_suggestions {database_handle} Returns list of suggestions not met in the current system. "SYSINSTALL/structure.tcl" (required) Provides: proc structure {} Returns value of type package_structure "SYSINSTALL/signature" (optional) Provides: "SYSINSTALL/install.tcl" (required) Provides: proc install {database_handle package_stream package} Returns error message if package cannot be installed or an empty string in case of success. See section Installation for details. proc upgrade {database_handle package_stream package} Returns error message if package cannot be installed or an empty string in case of success. See section Upgrade for details. proc uninstall_proc Returns proc uninstall {database_handle package} proc uninstall should return error message if package cannot be uninstalled or an empty string in case of success. See section Uninstallation for details. files containing package data ====================================================================== . Files ownership ====================================================================== Package::disown and Package::own are to be used to remove/add file ownership to the specified package. A. If Package::install puts file somewhere and this file does not exist there the file considered to be owned by the package. Record about ownership is to be put in the database including file permissions, MD5 etc. B. If Package::install wants to put file somewhere and this file already exists database is queried for packages owning this file. a) No other packages own this file. Depending on user original file could be saved in the same directory by adding some suffix (e.g. ".sysinstall-save-") or original file could be copied to some directory before writing file from package. Package owns this file. b) File is owned by other packages. Callback::file_to_be_installed_exists_and_owned_by_other_packages is to be called and if it returns an empty string installation is continued and file is overwritten, if callback returns non-empty string installation is aborted with error message returned by the callback. User is provided with information about other packages owning this file and depending on user: 1. original file could be saved like in a), it will be owned by those packages, new file is put and owned by the new package only. I.e. records of other packages are updated to own saved file but not newly put file. 2. Original file is left as is, new package owns it as well as old packages, file from the package is not put. 3. Original file is not saved and new file is put over it. New package owns it as well as old packages, records for old packages are probably updated to match new file (md5, inode etc.) 4. File is a text file and could be patched to be compatible with all packages. New package owns it as well as old packages, records for old packages are probably updated to match new file (md5, inode etc.) 5. Installation of the new package is aborted and undone. User is asked to remove conflicting packages and restart installation. C. The file is shared between several packages and one of these packages is being uninstalled. If this file was patched during installation of the package being currently uninstalled reverse patch is applied. Otherwise the file is left untouched. D. The file is shared between several packages and one of these packages is being undone. If packages being undone is latest by installation time among all packages owning this file the file is replaced with saved (by undo system) version. Otherwise file is left untouched. E. The file is owned by a package being uninstalled only. If MD5 of the file is the same as recorded in the database the file is silently removed. If MD5 of the file is not recorded in the database the file is silently removed. If MD5 of the file is recorded in the database and differs from MD5 of the real file user is asked to choose: view the file and then return to this menu, remove the file, leave the file and probably have problem of unreferenced file later, move the file to another location (preferably into directory which is not handled by the package system). F. Directory D is owned by package A only. D contains file F which is not owned by A. User uninstalls A. a) F is owned by B, D is not owned by B. Ownership of D is transfered to B, D is not removed. b) F is not owned by any package. User chooses: view F and then return to this menu, remove F, leave F and D (not owned by anything) and probably have problem of unreferenced file later, move F to another location (preferably into directory which is not handled by the package system). ====================================================================== . Package creation ====================================================================== New package could be created by calling PackageCreator::create_package. User should prepare directory with files and directories to be placed in a new package. Default scripts for a package could be generated by PackageCreator::generate_procs. This could be used to start creating package with modified procs. Note it is recommended to remove not modified procs from the generated files before using PackageCreator::create_package. This PackageCreator::create_package proc does the following: 1. If package file being created already exists exception is raised. 2. Builds list of files to be put into package 3. Output package stream is opened using Stream::create and then package_creator is opened using PackageCreator::create 4. Reads SYSINSTALL/description.tcl if it exists, generates necessary procs if they absent, writes SYSINSTALL/description.tcl into archive. Name is generated using package file name being created sans directories and suffix. Description and summary is generated using some default strings. Author is generated using /etc/passwd entry for the current user. Canonical name and references are generated to be empty. 5. Reads SYSINSTALL/features.tcl if it exists, generates necessary procs if they absent, writes SYSINSTALL/features.tcl into archive. List of provided features if generated contains the same feature as package name with version extracted from package name or 0.0. If there are binary executables among files to be included in the package they are scanned for shared libraries necessary to run these executables (using ldd) and if these libraries are not among files being included into the package other packages are found owning these libraries and features provided by these packages are included into requirements lists for the new package. proc requires and check_requirements are generated using this list. Empty list of conflicting packages is generated and conflicts and check_conflicts are generated accordingly. could_be_installed_proc is generated to return procs doing nothing and returning 1. could_be_uninstalled_proc is generated to return procs checking if each feature from the list specified is required by this package. If there is at least one feature in the list required by this package and system provides no suitable other versions of this feature (Database::feature_other_versions) returns 0, otherwise returns 1. check_users_groups_requirements is generated to return a list of two empty lists. check_suggestions is generated to return an empty list. 6. Reads SYSINSTALL/structure.tcl if it exists, generates necessary procs if they absent, writes SYSINSTALL/structure.tcl into archive. Note proc structure if supplied by the package creator is not checked. proc structure is generated (if not supplied by user): Default prefix is /usr/local. If there are files in man subdirectory they are put into man subpackage. If there are files in doc subdirectory they are put into doc subpackage. References list is created to be empty. Replacement scheme for files is "" (i.e. use default scheme). If there are files with suffixes .si2-diff or .si2-patch they are considered to be patches for already present (at the installation time) files with names sans these suffixes. If there are files with suffix .si2-append they are considered to be appended to probably already present (at the installation time) files with names sans these suffixes. 7. If SYSINSTALL/signature exists writes SYSINSTALL/signature into archive. 8. Reads SYSINSTALL/install.tcl if it exists, generates necessary procs if they absent, writes SYSINSTALL/install.tcl into archive. See sections Installation and Upgrade for description of procs to be generated. 9. Puts files supplied by the package creator into archive 10. Calls PackageCreator::close ====================================================================== . Logging ====================================================================== ???? A one-line syslog entry summarising activity if system modifications were made, eg: si2: package 'foobar-1.4' upgraded to 'foobar-1.6' ====================================================================== . Pseudo-packages ====================================================================== ???? ====================================================================== . Garbage collection ====================================================================== 1. Filesystems are scanned (at night, once a week, once a month) for a directory owned by a package but containing files (or directories) owned by other packages or not owned at all. This information is saved in the database and message is sent to sysadmin. Using sysinstall user could put some of the conflicts found into ignore list in the database, uninstall conflicting packages, remove or move not referenced files etc. : This is for catching the sorts of files that might have been created by : the package but not part of the original archive? This could be : supplemented with some hinting: : : - A hint associated with a directory that indicates that any files in : the directory should be treated (by uninstall, etc.) as belonging to : the package/feature. : - A hint indicating that nominated files or directories should be : considered as being owned by the package (used if eg. the package : creates a temporary or working directory somewhere). 2. Packages could be divided in two categories: those which have immediate use (e.g. emacs or ftpd) and those which have no immediate use (e.g. shared library). I mean disk could be flooded with not required by other packages shared libraries (e.g. obsolete versions of them). Package creator could add attribute to his package marking it has no immediate use. Database could be scanned for those packages which are not required by other packages at the moment, report results to user and allow her to uninstall them. ???? ====================================================================== . Internationalization ====================================================================== ???? --UlVJffcvxoiEqYs2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message From owner-freebsd-libh Fri Mar 30 10: 9:10 2001 Delivered-To: freebsd-libh@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 8A86337B720 for ; Fri, 30 Mar 2001 10:09:07 -0800 (PST) (envelope-from mwm@mired.org) Received: (qmail 95165 invoked by uid 100); 30 Mar 2001 18:09:06 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15044.52162.152706.446427@guru.mired.org> Date: Fri, 30 Mar 2001 12:09:06 -0600 To: Alexander Langer Cc: Mike Meyer , Jordan Hubbard , chrisc@vmunix.com, kris@obsecurity.org, libh@FreeBSD.ORG, op-tech@openpackages.org Subject: Re: PackageNG and OpenPackages In-Reply-To: <20010330170641.B10197@cichlids.cichlids.com> References: <20010329132249.A6943@xor.obsecurity.org> <20010329140754K.jkh@osd.bsdi.com> <15043.49939.888504.953014@guru.mired.org> <20010330170641.B10197@cichlids.cichlids.com> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anoyne working on updating packages should probably be aware of - if not have looked at - Anton Berezin's BSDPAN facility at (unless there's a newer version). It extends the Perl module system so that modules are automatically installed as packages. It also makes module installation PREFIX clean, which the standard PERL module install doesn't do. That failing is responsible for about 50% of the ports I see that aren't PREFIX clean. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message