On Thu, Jun 09, 2005 at 08:35:25AM -0400, David R. Morrison wrote:
>
> On Jun 8, 2005, at 1:48 PM, Jean-Fran?ois Mertens wrote:
>
> >
> >The arguments were :
> >1) It represents a loss in the language: the new behaviour was trivial
> >to obtain under the old semantics by 'fink build foo; fink
> >reinstall foo',
> >while I see no way to reimplement the old semantics currently...
> >2) Stability of the language :
> >Users might have scripts that depend on the old behaviour..
> >(I no longer have _ but I did). In that sense one might wish to argue
> >that if a new meaning is given, it depends on some flag (eg,
> >reinstall -b ,
> >"b" for build), and that original meanings be preserved if possible...
> >(Example of such use :
> >Take a script by which a user is doing his own installs (whether it be
> >in order to save logs, or in order to always build things in
> >dependency order,
> >or to enforce own preferences like eg to install 'all possible
> >splitoffs
> >that have been built', or ..).
> >For the script to be effective even for rebuilds, it has to start with
> >fink rebuild foo; next it has then to issue a reinstall command
> >(possibly
> >for the whole foo-family), and it is important that this does not
> >re-attempt
> >a build that has just failed...
> >)
> >
> >A prompt is a pain when writing scripts: one would have to try
> >piping an
> >'echo no' to the command (there is no fink -n reinstall ...).
> >So I would suggest either
> >1) use 'fink reinstall -b' for the new semantics and keep the old
> >meaning
> >of fink reinstall.
> >2) or, if stability of the language is deemed unimportant, preserve
> >the
> >old semantics under some additional flag to reinstall.
> >
> >
>
>
> Here's another possibility: this issue arose in situations in which
> "fink reinstall" fails because it doesn't find a .deb. So how about
> this:
> "fink reinstall" works as before unless it doesn't find a .deb .
> If it doesn't find one, it prompts the user with a message about this
> and asks if the user would like to build the package. Perhaps even
> this latter behavior could be overridden with a flag.
That's the "we could wrap it in a prompt" variation I proposed, no? If
it does find a .deb, there's no issue here ('fink reinstall' if a .deb
does exist does not and would not rebuild, since we prefer to do the
minimum necessary to satisfy a user's request).
Ikay, what if we have a tri-state flag (fink.conf and/or cmdline), say
--rebuild-if-needed (feel free to propose a better name obviously)
that controls what to do if we need to reinstall but there's no .deb?
true: build it (or first try to download, if we're configured that way)
false: abort (this is the current behavior)
undef: prompt the user (default answer=true)
This is a "new" situation fink is learning how to handle so by default
we ask the user what to do, but we lean towards making fink more
automatic. If user really never wants an "unrequested" build (i.e.,
the 0.24 behavior) he can request that, likewise if he wants a more
seemless "do whatever implicit actions are needed to do what I said to
do".
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
