Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jul 2002 01:01:49 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Cy Schubert - CITS Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Cc:        Terry Lambert <tlambert2@mindspring.com>, arch@FreeBSD.ORG
Subject:   Re: Package system wishlist
Message-ID:  <3D2E8CED.9A6B30D3@softweyr.com>
References:  <200207120457.g6C4vux4006072@cwsys.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2E8CED.9A6B30D3>