lock package option for setup (was: Re: Inconvenient ghostscript and transfig dependences)

[Yitzchak Scott-Thoennes]

On Wed, Dec 21, 2005 at 10:57:42AM -0500, Igor Pechtchanski wrote:
> On Wed, 21 Dec 2005, Yitzchak Scott-Thoennes wrote:
> 
> > On Tue, Dec 20, 2005 at 07:24:56PM -0500, Larry Hall (Cygwin) wrote:
> > > Sorry but there is currently no way to represent "either/or"
> > > dependencies via "setup.exe" (PTC).  That said, there's no reason that
> > > you can't override "setup.exe" and not install gs-no-X11.  If you know
> > > that's what you want, then you should feel free to do so.  If your
> > > gripe is that "setup.exe" will try to install gs-no-X11 each time you
> > > run it, you should feel free to manually edit /etc/setup/install.db to
> > > include the package name and an impossibly high version number to fool
> > > "setup.exe" into thinking you already have a version installed that is
> > > more current than what it has available to it.
> >
> > This keeps getting advocated, but in my testing it does *not* work.
> > If you have found otherwise, or see somewhere in the source for setup
> > where this is supposedly implemented, please give some detailed
> > information.
> >
> > But AFAICT, setup seems to have no concept of higher/lower version
> > numbers, nor do I see how setup *could* understand the variety of
> > version numbers out there.  Which is higher, 20030307 or 1.875?
> > 2.5.4a or 2.5.4?  2.8.0 or 2.10.1?  These all involve assumptions
> > that may or may not be true.
> 
> Yes, you're correct.  I've also been occasionaly guilty of recommending
> this option, and it indeed does not work.  The code in setup.exe only
> checks for version equality, so if you have "installed != current",
> "current" will be selected, even if "installed" is higher (for some
> definition of higher).
> 
> It might be quicker (and easier) to implement a "lock package" option in
> installed.db, so that locked packages never get upgraded, even if their
> version is not the same as "curr".  <http://cygwin.com/acronyms/#PTC>
> (which I will provide eventually, though someone else is welcome to beat
> me to it).

Vague thoughts...

Maybe have each package to have Keep (that is, locked), Curr, and Exp
options that get stored in installed.db, with Curr being the default,
and add a "Default" radio button to the set at the top in setup.exe.
But if the user selects Keep, Curr, or Exp in setup, that overrides
the saved per-package stuff.  I can't think of a clean way to allow
setting things to Keep, etc., though; for now at least being able to
hand edit installed.db would be great.