From owner-freebsd-arch Wed Jul 10 19:18:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D212D37B400 for ; Wed, 10 Jul 2002 19:18:15 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B68243E3B for ; Wed, 10 Jul 2002 19:18:15 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-3.customer.nethere.net ([209.132.102.163] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17STWq-000O1M-00; Wed, 10 Jul 2002 20:18:00 -0600 Message-ID: <3D2CEBCE.55DC3C6D@softweyr.com> Date: Wed, 10 Jul 2002 19:22:06 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Cy Schubert - CITS Open Systems Group Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: Package system wishlist References: <200207101459.g6AExQfP034695@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cy Schubert - CITS Open Systems Group wrote: > > In message <3D2BE142.E25CA9BC@mindspring.com>, Terry Lambert writes: > > So, following Jordan's advice, what's on everyone's wishlist? > > > > Terry's Wishlist: > [...] > > + Cy's Wishlist: > > o Optional installation of sources. RH's SRPM's is a very poor > example of this. A better example would be what IBM does to > install JES/2 on their MVS system, e.g. an OpenSSH package might > contain source in addition to binaries. The sources would be > installed in /usr/src while the binaries would be installed > in /usr/bin, sbin.... Yes! My mythical XML metadata format, with or without external "filesets", would handle this with aplomb. The source set would be included in the metadata and you could skip it or install it as with any other fileset. Come to think of it, you could include the ports Makefile and patches as well. Hmm, that bears some thinking about. Most of what is in a "port" right now is metadata too. > o Files replaced by a package backed up in case of package removal I'm not sure what you mean here. Be able to create a backup script of the files related to a package for backing up? Be able to restore only missing files from a package? Both seem like good ideas... > o Check option: Tell me what it will do without doing it > > o Group option: Install prerequisites Wouldn't you want this to be the default, perhaps with an option to abort if they're not "readily available"??? > o Groupextend option: Install postrequisites, e.g. dependent > packages and patches In other words, roll portupgrade into the system. > o Ability to install my own packages on top of packages and > patches, I like to call them USERMODS. Your own packages or your changes to a standard package? I can see the value, but how to do it doesn't leap immediately to mind. > o The package system should be independent of the compression tool > used. In the future new compression algorithms and tools will > be developed. The package system should be flexible enough to > not care how its files are compressed or packaged. Ditto for archive formats, encoding formats, etc. We should probably specify one of each as a bare minimum, choosing from those that are available in library format, reasonably licensed, and have acceptable performance (for some definition of acceptable). > o The ability to export and import the package database (currently > to clone systems, I rsync /usr/local, /usr/X11R6, and /var/db/pkg > to a new system I am installing, this saves many hours of work). Yes, perhaps even the ability to capture a currently installed package and turn it back into a package file. That'd be way cool for duplicating packages with local customizations. > > o I want to be able to remove system components, like "sendmail" > > and "OpenSSH". > > Ideally everything should install as a package, however that would > create a lot of extra work for us developers. I have yet to think of a > painless way to do this. Yeah, Debian has certainly showed us how NOT to do it. "Which version of /bin/cat do you want?" -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message