date:20050504

Re: Welcoming Brian Dessent as setup maintainer

2005-05-04 Thread Corinna Vinschen

On May  3 23:48, Igor Pechtchanski wrote:
 FWIW, I like the --expert option suggested by CGF.

I like the idea of having an expert and a dumm^Wstandard mode, but
I would rather see a switch in the GUI, than just in the CLI.

I think it should be possible to override dependencies on the fly and
as Igor, I'm doing that pretty often.  I don't think setup should be
degraded to a tool just for the really challenged.  After all, even
some of the better Linux GUI installer tools allow to override package
dependencies.

To say it in other words: From my point of view there's an installer
functionality which is implemented apart from the GUI and the job of
the GUI is to give GUIfied access to all installer functionality.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

RE: Welcoming Brian Dessent as setup maintainer

2005-05-04 Thread Dave Korn

Original Message
From: Brian Dessent
Sent: 04 May 2005 04:12

 The only one that makes any sense is when you're trying to uninstall a
 large dependency tree, such as if you want to get rid of X11.  The last
 time I tried this it was quite hard, since you would turn off one
 package, but in the process of cycling the next you would wind up
 re-enabling the one you just turned off.  I think it's possible to do it
 but you have to do something really stupid like put half the packages in
 'Source', then disable the other half, then finally you can cycle the
 first set to Uninstall since there's no version number in between Source
 and Uninstall.  Makes me kind of sick just thinking about expecting
 someone not familiar with setup to figure that out.
 
 I guess that gets into a whole other area though, that you should either
 be able to mass-deselect a number of packages at once, or have some way
 of deselecting a package without cycling through other versions of it.
 :/

  Mass selection, and a right-click context menu.  I'll take a look at that
too.

 But back to Larry's point.  Should we refuse to even give them the rope
 lest they hang themselves?

  Yep.  Absolutely.  Hey, as far as I'm concerned, anytime anyone clicks the
'install in text mode' or 'just for me' buttons, a little sign should light
up, saying Please do not click on this button again.

  Hell, let's make it a compile-time option.  Anyone who *really* knows what
they're doing can build their own local copy of setup with
-DNO_I_REALLY_DO_WANT_TO_MESS_UP_MY_INSTALL

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [patch] manifest, and test release

2005-05-04 Thread Max Bowsher

Brian Dessent wrote:
Max Bowsher wrote:
There is one remaining issue - here is a ChangeLog entry from the current
release branch:
2004-11-28 Max Bowsher [EMAIL PROTECTED]
* download.cc (check_for_cached): Re-introduce the silent
skipping
of
wrong-sized package files in local caches, as a quick fix that
is
no
worse than the status quo, to be able to make a release, whilst
work towards a proper fix continues on trunk.
Yuck... that sounds like one of those corner cases that's never fun to
deal with - do you try to resume the transfer, and hope the md5sum is
correct, or do you just delete ir or rename it out of the way.
OK, I've refreshed my memory on the situation.
Currently, setup just ignores wrongly sized files. I fixed that, but
thinking it would be a rare situation, didn't bother with nice error
handling, and just threw an exception.

To fix this, we just need to change to two cases where an exception is
thrown in download.cc, with the message Package validation failure, to
instead just warn nicely, and move the bad file out of the way.

I think a MessageBox is sufficient for now, but it might want to become part
of a report textbox, as a further refinement.

I will try to look more into the oddity reported earlier today...
+name=RedHat.Cygwin.Setup
... perhaps just Cygwin.Setup here ?
To be honest I have no idea, but was going by what the SDK says. About
'name' it says: Uniquely names the application or assembly. Use the
following format for the name: Organization.Division.Name. For example
Microsoft.Windows.mysampleApp. Required.
Then perhaps Cygwin.Setup.Setup ?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/manifest_files_reference.asp
Actually, reading through those docs again I'm slightly worried about
the version thing again:
Every side-by-side assembly must have a version. Each assembly version
is associated with a version number having four parts separated by
periods: major.minor.build.revision. If a change is made to an assembly
making it incompatible with existing versions, the major or minor parts
of the version number must be changed. A version number that changes
only in the build or revision parts indicates that the assembly is
backward compatible with prior versions.
We could, without too much hassle, run sed on the thing at build time to
subsitute the ChangeLog version in there, adding 0s as necessary for
missing fields. However, I have to wonder what they really mean when
they say, change is made to an assembly making in incompatible. As
far as I know, that seems to apply more to their .NET stuff, where these
manifests actually contain useful information. From what I can tell,
the only thing this is doing in our case is saying, Yes, I'd like the
comctl32 version 6 please, thank you and that's it. So I guess it's
fine to leave the version at 1.0.0.0 indefinitely.
I think it is fine.
It would only be necessary to do meaningful things with the version number
if other SxS assemblies were going to be depending on *us*.

1 2 >

1 - 100 of 108 matches

Mail list logo