This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: astksh review


On Fri, 23 May 2003, Charles Wilson wrote:

> Igor Pechtchanski wrote:
>
> > This also relates to an issue that I wanted to raise earlier: when doing a
> > search for files at <http://cygwin.com/packages/>, those files that are
> > created by postinstall scripts (e.g., symlinks) will not show up in the
> > listing.
> > So, it might be a good idea to keep a manifest of files that would be
> > potentially created by postinstall scripts, and to remove those files when
> > the package is removed.  It's possible that setup will have a separate
> > mechanism for tracking this.  Frankly, I don't have a concrete suggestion
> > on how to implement this, but thought I'd at least get this into the
> > archives and make people aware of the issues.
>
> Actually, all us package maintainers ought to do a better job including
> "pre-remove" scripts in addition to post-install scripts, that would
> clean up anything created by the postinstaller.  Yep -- setup supports
> this -- but most maintainers (I'm guilty here...) don't bother:
>
> Who'd EVER want to uninstall MY package? <g>
> --Chuck

Chuck,

I think that is actually true for some of your packages... ;-)

Seriously, though, it's not that simple.  Not only will the maintainers
have to come up with preremove scripts, these preremove scripts will have
to get some information from the postinstall scripts (maybe even be
dynamically modified by them) to indicate which files were actually
changed or created!  For example, if your postinstall script is capable of
creating a symlink to, say, ksh, this doesn't mean that the link is
actually created.  That doesn't look like an issue with most of your
packages, although you do create some symlinks in the postinstall scripts,
so they'll need to be removed (unconditionally).

Another issue with preremove scripts is dependences.  The preremove
scripts currently run before each individual package is uninstalled, not
all together like the postinstall scripts.  Furthermore, the files that
the preremove script deletes might be necessary for other preremove
scripts to run.  I'm not even convinced that running preremove scripts in
reverse order of dependences is going to work if package dependences are
used.  We'll need to think on that one.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]