From owner-freebsd-arch Fri Jul 12 0:57:56 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 3ABCD37B400 for ; Fri, 12 Jul 2002 00:57:52 -0700 (PDT) Received: from softweyr.com (softweyr.com [65.88.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE7743E42 for ; Fri, 12 Jul 2002 00:57:46 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from nextgig-8.customer.nethere.net ([209.132.102.168] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17SvJ4-000OrH-00; Fri, 12 Jul 2002 01:57:38 -0600 Message-ID: <3D2E8CED.9A6B30D3@softweyr.com> Date: Fri, 12 Jul 2002 01:01:49 -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: <200207120457.g6C4vux4006072@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: > > Sorry for the late reply, management course. > > In message <3D2CEBCE.55DC3C6D@softweyr.com>, Wes Peters writes: > > Cy Schubert - CITS Open Systems Group wrote: > > > > > > + 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. > > IBM used UCL. XML is better. > > > > > > 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... > > If for example openssh-overwrite-base-3.4p1 is installed, the old > binaries are saved (backed up) before the package is installed. If I > pkg_delete openssh-overwrite-base-3.4p1, the old ssh files are restored > (reappear). Oh, OK, now I see. Yes, of course. ;^) > > > 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"??? > > You're right. Then there should be an option to just install the > selected packages and nothing else. This would allow for "creative" > problem solving. And for just jamming Gimp onto the system when you know it'll do what you want without lib{greatestgraphicsformatnobodyuses}.so. > > > o Groupextend option: Install postrequisites, e.g. dependent > > > packages and patches > > > > In other words, roll portupgrade into the system. > > Yes. This (and mergemaster as Terry pointed out) need to be done anyhow. > > > 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. > > This increases the complexity of the proposed package system. This was > mentioned as a possible ideal. I doubt this feature would be used > much. Please use it as you see fit. Something to think about for the future. Terry mentioned being able to re-encapsulate edited configuration files, etc. For example, a package that installs a conf.example file should have the real conf file associated with it in some way, too. > > > 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?" > > Exactly. This had its usefulness in the mainframe world where > decisions made years ago would cost millions of dollars to undo. OTOH, > choosing a SYSV init v.s. a BSD init might be nice (just an example, no > flames please). Ultimately striking the proper balance is our goal. > Please pick and choose any ideas as you see fit. With some nice, canned configurations that do a good approximation of working out of the box. -- "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