RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Wednesday, July 25, 2001 5:55 PM
> To: Dario Alcocer
> Cc: cygwin@cygwin.com
> Subject: Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
> 
> 
> Sounds cool, Dario.  How have your db and rpm ports been generated? 
> Which versions are you using, db-3 and rpm-4, or db-2 and 
> rpm-3 ?  Is db 
> built as a dll, or as a static lib ?
> 
> BTW, for your purposes perhaps you could pack up your bootstrap 
> environment into a self-extracting zip file ?
> 

Or as the installer user interface is tcl/tk-based, you can look at FreeWrap
( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its neat and
works quite well; moreover the tcl/tk installer in this case do not NEED
cygwin, so can unpack the basic bootstrap environment without any problem).

HTH

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Bernard" == Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:

    Bernard> Or as the installer user interface is tcl/tk-based, you
    Bernard> can look at FreeWrap
    Bernard> ( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its
    Bernard> neat and works quite well; moreover the tcl/tk installer
    Bernard> in this case do not NEED cygwin, so can unpack the basic
    Bernard> bootstrap environment without any problem).

Yes, I guess this would work as well.  However, the main reason I
didn't want eliminate the Cygwin DLL was that I wanted to use ash to
run the RPM package post-install/pre-uninstall scripts with it.  I
guess I could find a Win32 Bourne-compatible shell that didn't require
Cygwin to replace ash, but that would still leave me looking for
Win32-only ports of the other utilities that might be required by the
scripts (e.g. awk, sed, cut, paste etc.)

In the end, it just seemed simpler that, rather than trying to avoid
including Cygwin in the installer (and miss out on all that
functionality), I should instead find a way to use cygwin1.dll and
avoid the pitfalls instead.  I decided on a two-stage install process;
the first stage would check for a duplicate cygwin1.dll loaded in
memory (and abort with a message if one was found), and the second
stage would be the actual Tcl/Tk installer.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> >>>>> "Bernard" == Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:
> 
>     Bernard> Or as the installer user interface is tcl/tk-based, you
>     Bernard> can look at FreeWrap
>     Bernard> ( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its
>     Bernard> neat and works quite well; moreover the tcl/tk installer
>     Bernard> in this case do not NEED cygwin, so can unpack the basic
>     Bernard> bootstrap environment without any problem).
> 
> Yes, I guess this would work as well.  However, the main reason I
> didn't want eliminate the Cygwin DLL was that I wanted to use ash to
> run the RPM package post-install/pre-uninstall scripts with it.  I
> guess I could find a Win32 Bourne-compatible shell that didn't require
> Cygwin to replace ash, but that would still leave me looking for
> Win32-only ports of the other utilities that might be required by the
> scripts (e.g. awk, sed, cut, paste etc.)
> 
> In the end, it just seemed simpler that, rather than trying to avoid
> including Cygwin in the installer (and miss out on all that
> functionality), I should instead find a way to use cygwin1.dll and
> avoid the pitfalls instead.  I decided on a two-stage install process;
> the first stage would check for a duplicate cygwin1.dll loaded in
> memory (and abort with a message if one was found), and the second
> stage would be the actual Tcl/Tk installer.

Unfortunately that still has the potential for trouble:

1) consider an ash script run when updating ash?
2) Consider other scripts running when updating ash?
3) Consider rpm updating itself ?

I'm not trying to throw cold water on this - just to raise some
considerations.

IMO, the setup program should update cygwin1.dll; force a reboot if
needed to get the new dll copied in (MS document how to do this); then
call into cygwin linked programs to do the real work (including rpm).
Cygwin1.dll needs to provide an abstracted replace-file-on-reboot
functionality, and the installing package stops as soon as such an
occurence happens triggering another reboot...

Thoughts?

Rob



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Charles Wilson]

Robert Collins wrote:

> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> 
>>>>>>>"Bernard" == Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:
>>>>>>>
>>    Bernard> Or as the installer user interface is tcl/tk-based, you
>>    Bernard> can look at FreeWrap
>>    Bernard> ( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its
>>    Bernard> neat and works quite well; moreover the tcl/tk installer
>>    Bernard> in this case do not NEED cygwin, so can unpack the basic
>>    Bernard> bootstrap environment without any problem).
>>
>>Yes, I guess this would work as well.  However, the main reason I
>>didn't want eliminate the Cygwin DLL was that I wanted to use ash to
>>run the RPM package post-install/pre-uninstall scripts with it.  I
>>guess I could find a Win32 Bourne-compatible shell that didn't require
>>Cygwin to replace ash, but that would still leave me looking for
>>Win32-only ports of the other utilities that might be required by the
>>scripts (e.g. awk, sed, cut, paste etc.)
>>
>>In the end, it just seemed simpler that, rather than trying to avoid
>>including Cygwin in the installer (and miss out on all that
>>functionality), I should instead find a way to use cygwin1.dll and
>>avoid the pitfalls instead.  I decided on a two-stage install process;
>>the first stage would check for a duplicate cygwin1.dll loaded in
>>memory (and abort with a message if one was found), and the second
>>stage would be the actual Tcl/Tk installer.
>>
> 
> Unfortunately that still has the potential for trouble:
> 
> 1) consider an ash script run when updating ash?
> 2) Consider other scripts running when updating ash?
> 3) Consider rpm updating itself ?
> 
> I'm not trying to throw cold water on this - just to raise some
> considerations.
> 
> IMO, the setup program should update cygwin1.dll; force a reboot if
> needed to get the new dll copied in (MS document how to do this); then
> call into cygwin linked programs to do the real work (including rpm).
> Cygwin1.dll needs to provide an abstracted replace-file-on-reboot
> functionality, and the installing package stops as soon as such an
> occurence happens triggering another reboot...
> 


**IF** you're going to pursue this, The Right Way(tm) is to build a 
special cygwin1.dll AND import lib environment, where the "shared memory 
region name" is different -- and perhaps the dll name itself, as well. 
Also, it should use a different registry key for mounts and such, 
probably. (Check the cygwin archives wrt. error_start and gdb for some 
info on how to do the "shared memory region name" thing).  Then, build 
your special ash and rpm and db and utils within that environment (you 
may need to also build gcc?)

Okay, so no2 you've got a nice, self-contained "cygwin"-based 
mini-environment that will not interfere with a "real" cygwin 
environment.  So, the mini-environment should be able to update anything 
in the real environment, with the usual caveats about files in-use by 
"real" cygwin programs.

The difficulty here is you've got to maintain TWO separate binaries for 
your core utilities -- one set of (cygwin itself, ash, rpm, db, etc) for 
the "real" system and one set for the "mini" environment.

--Chuck






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:

    Chuck> **IF** you're going to pursue this, The Right Way(tm) is to
    Chuck> build a special cygwin1.dll AND import lib environment,
    Chuck> where the "shared memory region name" is different -- and
    Chuck> perhaps the dll name itself, as well.  Also, it should use
    Chuck> a different registry key for mounts and such,
    Chuck> probably. (Check the cygwin archives wrt. error_start and
    Chuck> gdb for some info on how to do the "shared memory region
    Chuck> name" thing).  Then, build your special ash and rpm and db
    Chuck> and utils within that environment (you may need to also
    Chuck> build gcc?)

    Chuck> Okay, so no2 you've got a nice, self-contained
    Chuck> "cygwin"-based mini-environment that will not interfere
    Chuck> with a "real" cygwin environment.  So, the mini-environment
    Chuck> should be able to update anything in the real environment,
    Chuck> with the usual caveats about files in-use by "real" cygwin
    Chuck> programs.

    Chuck> The difficulty here is you've got to maintain TWO separate
    Chuck> binaries for your core utilities -- one set of (cygwin
    Chuck> itself, ash, rpm, db, etc) for the "real" system and one
    Chuck> set for the "mini" environment.

I think this would be the major sticking point; having a parallel
set of Cygwin binaries would be problematic, both for maintenance and
support.

I think the approach I've outlined in the following message should
work:

    http://www.cygwin.com/ml/cygwin/2001-07/msg01508.html

Please let me know what you think regarding this approach.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 26 Jul 2001 08:36:37 -0700, Dario Alcocer wrote:
> >>>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:
> 
>     Chuck> **IF** you're going to pursue this, The Right Way(tm) is to
>     Chuck> build a special cygwin1.dll AND import lib environment,
>     Chuck> where the "shared memory region name" is different -- and
>     Chuck> perhaps the dll name itself, as well.  Also, it should use
>     Chuck> a different registry key for mounts and such,
>     Chuck> probably. (Check the cygwin archives wrt. error_start and
>     Chuck> gdb for some info on how to do the "shared memory region
>     Chuck> name" thing).  Then, build your special ash and rpm and db
>     Chuck> and utils within that environment (you may need to also
>     Chuck> build gcc?)

Mounts shouldn't be changed - it needs to install into the cygwin
mounted directories. 
 
>     Chuck> The difficulty here is you've got to maintain TWO separate
>     Chuck> binaries for your core utilities -- one set of (cygwin
>     Chuck> itself, ash, rpm, db, etc) for the "real" system and one
>     Chuck> set for the "mini" environment.

The mini environment shouldn't need different binaries, just a copy in
the toolkit, launched with a custom PATH.

> I think this would be the major sticking point; having a parallel
> set of Cygwin binaries would be problematic, both for maintenance and
> support.

I don't think changing the .dll name would be needed - it would be outof
the system path, and in the same dir as all the binaries for the
toolkit. Changing the shared memory area is needed IMO, but that can be
done by a simple #ifdef in one location in the cygwin dll source. ie #if
_CYGWIN_INSTALLER_DLL_
#else
#endif 

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Charles Wilson]

Dario Alcocer wrote:

>     Chuck> The difficulty here is you've got to maintain TWO separate
>     Chuck> binaries for your core utilities -- one set of (cygwin
>     Chuck> itself, ash, rpm, db, etc) for the "real" system and one
>     Chuck> set for the "mini" environment.
> 
> I think this would be the major sticking point; having a parallel
> set of Cygwin binaries would be problematic, both for maintenance and
> support.
> 
> I think the approach I've outlined in the following message should
> work:
> 
>     http://www.cygwin.com/ml/cygwin/2001-07/msg01508.html

Ummm...in that message you DO talk about an "'installer-toolbox' version
of RPM".  I just like making things explicit: remember that executables
embed the filename of the DLLs on which they depend. 

So, if your "ITK" cygwin dll was named cygwin1.dll, then sure: you could
use the same rpm.exe both in the ITK and "for real".  But then, you're
deliberately installing two different cygwin1.dll's on a system (even
temporarily -- but what about people who like to keep the ITK around?). 
AND you have to play games with $PATH so that the "right" one is used in
the proper circumstances.  Sure, in THIS case the two dll's will not
cause the problems we've all grown to know and love, since they have
different shared region names.

But how do you explain that to your users?  "But I asked on the cygwin
list and they said never have two cgywin1.dll's.  So I deleted the one
with the newer timestamp from C:\cygwin\bin and left the one in
<desktop>\cygwin-itk\"

Geez. What a nightmare.

It seems easier (from a long-term, customer-support perspective) to
build the the ITK-cygwin dll with a different name (say,
cygwin1-itk.dll) and then link special versions of your ITK progs
against it.  So, you'd have:

cygwin1-itk
rpm-itk
ash-itk
textutils-itk
tcl/tk-itk

And that's probably it.  (Now that I think about it, you probably don't
need a special gcc for building the itk tools -- just swap two different
spec files...) Sure, short term this looks like hell.  But "The Right
Way To Do Things(tm)" usually does.  And is usually better in the long
run.  

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:

    Robert> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:

    >> >>>>> "Bernard" == Bernard Dautrevaux
    >> <Dautrevaux@microprocess.com> writes:
    >> 
    Bernard> Or as the installer user interface is tcl/tk-based, you
    Bernard> can look at FreeWrap
    Bernard> ( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its
    Bernard> neat and works quite well; moreover the tcl/tk installer
    Bernard> in this case do not NEED cygwin, so can unpack the basic
    Bernard> bootstrap environment without any problem).

    Dario>  Yes, I guess this would work as well.  However, the main
    Dario> reason I didn't want eliminate the Cygwin DLL was that I wanted
    Dario> to use ash to run the RPM package post-install/pre-uninstall
    Dario> scripts with it.  I guess I could find a Win32
    Dario> Bourne-compatible shell that didn't require Cygwin to replace
    Dario> ash, but that would still leave me looking for Win32-only ports
    Dario> of the other utilities that might be required by the scripts
    Dario> (e.g. awk, sed, cut, paste etc.)

    Dario> In the end, it just seemed simpler that, rather than trying to
    Dario> avoid including Cygwin in the installer (and miss out on all
    Dario> that functionality), I should instead find a way to use
    Dario> cygwin1.dll and avoid the pitfalls instead.  I decided on a
    Dario> two-stage install process; the first stage would check for a
    Dario> duplicate cygwin1.dll loaded in memory (and abort with a
    Dario> message if one was found), and the second stage would be the
    Dario> actual Tcl/Tk installer.

    Robert> Unfortunately that still has the potential for trouble:

Robert, just to clarify, the second-stage install would have all of
the Cygwin tools used by the installer in either a temporary directory
(in the case of a self-extracting installer) or on a CD-ROM (in the
case of a CD-ROM based installer); let's call this minimum collection
of RPM tools used by the installer the "installer toolbox."

The ash shell that would be run by RPM for the post-install and
pre-uninstall scripts would be the installer toolbox version, not the
one in the installation directory, nominally C:\Cygwin\bin\ash.exe.

    Robert> 1) consider an ash script run when updating ash?

OK, I think there are two cases to consider: installing the packages
with Tcl/Tk GUI installer, and installing packages by hand using RPM
directly on the command line.  In the first case, the installer
toolbox is available, and this version of ash is the one that runs the
RPM package scripts.  Keep in mind, DLL conflicts will be avoided by
verifying this in the first stage of the install.  So, ash should run
fine.  In the second case, yes, running an RPM script when updating
ash could be a problem.  However, the current RPM ash package I've
build doesn't have any post-install or pre-uninstall scripts, so it's
not a problem.  In the case that future ash RPMs require installer
scripts, we just make sure these are put into a separate sub-package,
so we know that we always have a valid ash to run RPM installer scripts.

    Robert> 2) Consider other scripts running when updating ash?

The only way I see this being a problem is if .  If it's any
consolation, this same problem in theory should affect the Linux
version of RPM as well, so we're no worse off.

    Robert> 3) Consider rpm updating itself ?

This shouldn't be a problem.  The way I think it should be handled is
that version updates to RPM should be handled by the installer anyway,
and the installer has its own "installer toolbox" version of RPM.
This should avoid conflicts with the installed version of RPM.

    Robert> IMO, the setup program should update cygwin1.dll; force a
    Robert> reboot if needed to get the new dll copied in (MS document
    Robert> how to do this); then call into cygwin linked programs to
    Robert> do the real work (including rpm).

I mean no disrespect to your comments, but I really dislike rebooting
*any* machine (even NT machines :-)), both as a programmer and as a
user.  Besides, there's no *need* to reboot, if we can impose slightly
on the user.

Here's what should happen: the first stage installer detects a Cygwin
DLL conflict, and determines which currently running application(s)
have links to cygwin1.dll.  We present this list to the user, saying
"we've noticed the following Cygwin app(s) are running.  Before you
can continue with the installation, please close these apps down.
Re-run the installer after you've done this."  By asking the user to
shut down the apps, we accomplish two things: cygwin1.dll gets
unloaded, and we avoid the reboot.

    Robert> Cygwin1.dll needs to provide an abstracted
    Robert> replace-file-on-reboot functionality, and the installing
    Robert> package stops as soon as such an occurence happens
    Robert> triggering another reboot...

I very much aspire to the design philosophy of Antoine de
Saint-Exupery:

    "You know you've achieved perfection in design,
     Not when you have nothing more to add,
     But when you have nothing more to take away."

This "replace file on reboot" feature would be a special case just to
accomodate the installer, and not a generally useful feature, IMO, for
porting general POSIX apps to Win32.  Besides, I think the approach
I've outlined above would work just fine, and would avoid adding any
unnecessary feature (i.e. not needed by a range of POSIX apps) to the
Cygwin DLL.

BTW, great comments, I really appreciate the time you took to analyze
the RPM installer design.  Thanks!

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 26 Jul 2001 08:30:14 -0700, Dario Alcocer wrote:
> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
> 
>     Robert> On 25 Jul 2001 14:08:02 -0700, Dario Alcocer wrote:
> 
>     >> >>>>> "Bernard" == Bernard Dautrevaux
>     >> <Dautrevaux@microprocess.com> writes:

> 
>     Robert> Unfortunately that still has the potential for trouble:
> 
> Robert, just to clarify, the second-stage install would have all of
> the Cygwin tools used by the installer in either a temporary directory
> (in the case of a self-extracting installer) or on a CD-ROM (in the
> case of a CD-ROM based installer); let's call this minimum collection
> of RPM tools used by the installer the "installer toolbox."

As Chuck has mentioned, that cygwin1.dll should have a different shared
memory region identifier, to prevent crashes :}.

> The ash shell that would be run by RPM for the post-install and
> pre-uninstall scripts would be the installer toolbox version, not the
> one in the installation directory, nominally C:\Cygwin\bin\ash.exe.

ok... how do you update that installer toolbox?
 
>     Robert> 1) consider an ash script run when updating ash?
> 
> OK, I think there are two cases to consider: installing the packages
> with Tcl/Tk GUI installer, and installing packages by hand using RPM
> directly on the command line.  In the first case, the installer
> toolbox is available, and this version of ash is the one that runs the
> RPM package scripts.  Keep in mind, DLL conflicts will be avoided by
> verifying this in the first stage of the install.  So, ash should run
> fine.  In the second case, yes, running an RPM script when updating
> ash could be a problem.  However, the current RPM ash package I've
> build doesn't have any post-install or pre-uninstall scripts, so it's
> not a problem.  In the case that future ash RPMs require installer
> scripts, we just make sure these are put into a separate sub-package,
> so we know that we always have a valid ash to run RPM installer scripts.
> 
>     Robert> 2) Consider other scripts running when updating ash?
> 
> The only way I see this being a problem is if .  If it's any
> consolation, this same problem in theory should affect the Linux
> version of RPM as well, so we're no worse off.

Unix allows the deletion and replacement of open files, win32 doesn't.
Thats the root of the problems I'm highlighting - so no, Linux is not as
badly off as we are :}.

>     Robert> 3) Consider rpm updating itself ?
> 
> This shouldn't be a problem.  The way I think it should be handled is
> that version updates to RPM should be handled by the installer anyway,
> and the installer has its own "installer toolbox" version of RPM.
> This should avoid conflicts with the installed version of RPM.

Again, how do the users update the toolbox? Or do they download a 5mb
install for the toolbox when it needs updating?

>     Robert> IMO, the setup program should update cygwin1.dll; force a
>     Robert> reboot if needed to get the new dll copied in (MS document
>     Robert> how to do this); then call into cygwin linked programs to
>     Robert> do the real work (including rpm).
> 
> I mean no disrespect to your comments, but I really dislike rebooting
> *any* machine (even NT machines :-)), both as a programmer and as a
> user.  Besides, there's no *need* to reboot, if we can impose slightly
> on the user.

I dislike the idea too :}. I also dislike many other things about win32
:>.

> Here's what should happen: the first stage installer detects a Cygwin
> DLL conflict, and determines which currently running application(s)
> have links to cygwin1.dll.  We present this list to the user, saying
> "we've noticed the following Cygwin app(s) are running.  Before you
> can continue with the installation, please close these apps down.
> Re-run the installer after you've done this."  By asking the user to
> shut down the apps, we accomplish two things: cygwin1.dll gets
> unloaded, and we avoid the reboot.

Uhmm, assuming the user actually knows whats going on. Consider a user
that is not the sysadmin of the machine, and doesn't know that sshd is
running. In theory, yes with user cooperation, you can do this. In
practice I suspect that saying "we have installed a new version of
cygwin1.dll, to make it take effect reboot your machine" will be less
prone to support questions.

>     Robert> Cygwin1.dll needs to provide an abstracted
>     Robert> replace-file-on-reboot functionality, and the installing
>     Robert> package stops as soon as such an occurence happens
>     Robert> triggering another reboot...
> 
> I very much aspire to the design philosophy of Antoine de
> Saint-Exupery:
> 
>     "You know you've achieved perfection in design,
>      Not when you have nothing more to add,
>      But when you have nothing more to take away."
> 
> This "replace file on reboot" feature would be a special case just to
> accomodate the installer, and not a generally useful feature, IMO, for
> porting general POSIX apps to Win32.  Besides, I think the approach
> I've outlined above would work just fine, and would avoid adding any
> unnecessary feature (i.e. not needed by a range of POSIX apps) to the
> Cygwin DLL.

Weeeel, what would be really nice would be a hack to cygwin's
delete-on-close queue, to allow the unix "delete this open file, now
write a new file with the same name" functionality, with cygwin setting
up a replace-on-reboot, and removing that replace-on-reboot if/when the
file is actually closed and able to be done manually. _And_ for cygwin
linked process, redirecting any opens to the queued replacement file :}.
That way the posix semantics would be present, for most files. However
such a hack could be very difficult to do _the right way_... and I'm not
going to get sidetracked by it :].

> BTW, great comments, I really appreciate the time you took to analyze
> the RPM installer design.  Thanks!

Thank you. The developer list has spent a bunch of time tossing around
various ideas - that was a synopsis of the critical issues that any
cygwin hosted installer has to overcome. (Note that cygwin used to have
a cygwin-hosted installer, and moved away from that post B20.1).

Rob

> -- 
> Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
> alcocer@helixdigital.com -- http://www.helixdigital.com



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:

    Robert> As Chuck has mentioned, that cygwin1.dll should have a
    Robert> different shared memory region identifier, to prevent
    Robert> crashes :}.

Just curious; can't we avoid a specially built version of cygwin1.dll
by making sure that cygwin1.dll isn't loaded when the installer runs?
Making a special verion of cygwin1.dll could add more confusion.

    Robert> ok... how do you update that installer toolbox?

The installer toolbox (drat, I should have called it the IRT, for
"installer run-time") would be updated only when:

    * a cygwin1.dll bug has been fixed that affects the installer

    * a cygwin1.dll feature has been added that is needed by a
      newer version of the installer.

In either of these cases, a new self-extracting binary for the
installer would be built which would include the updated installer
toolbox.  Note that the installer toolbox, AKA installer run-time, is
only used by the installer; the installed Cygwin would never use these
tools.

    Robert> Unix allows the deletion and replacement of open files,
    Robert> win32 doesn't.  Thats the root of the problems I'm
    Robert> highlighting - so no, Linux is not as badly off as we are
    Robert> :}.

OK, I didn't understand your original point.  Yes, I think the
solution here is to make sure that the RPM packages should not
included scripts that would exhibit this problem.

    Robert> Again, how do the users update the toolbox? Or do they
    Robert> download a 5mb install for the toolbox when it needs
    Robert> updating?

Users would not update the installer run-time, only the installer's
maintainer.  Since the installer run-time would be included in the
self-extracting installer (and would be delete automatically by the
installer after it's completed its job), the users would never really
have to know about it, or worry about updating it.  In fact, I believe
that installers built with InstallShield work in this fashion; they
can unpack a series of files to C:\WINDOWS\TEMP and run a second-stage
installer from there.

Regarding the size of the installer run-time, my current environment
is 1.5M compressed.  Since the stub EXE that would be prepended to
this archive to make it self-extracting would probably be only about
10-50KB, I'd guess that the self-extracting installer would not be
much bigger than 1.5M.  While this makes it considerably bigger than
the current setup.exe (~239K), it can still be downloaded in a
reasonable amount of time (6.9 minutes @ 28.8Kbps, 3.6 minutes @
56Kbps.) The biggest files in the run-time are cygwin1.dll, rpm.exe,
cygtk80.dll, and cygtcl80.dll.

    Robert> Uhmm, assuming the user actually knows whats going
    Robert> on. Consider a user that is not the sysadmin of the
    Robert> machine, and doesn't know that sshd is running. In theory,
    Robert> yes with user cooperation, you can do this. In practice I
    Robert> suspect that saying "we have installed a new version of
    Robert> cygwin1.dll, to make it take effect reboot your machine"
    Robert> will be less prone to support questions.

OK, how about adding two buttons on the dialog, "Retry" and "Reboot",
making Reboot the default choice.  The dialog box can tell the user to
shut down the Cygwin apps that were found and click on retry, or they
press Enter and accept the default action, which would reboot the
machine, clearing the loaded Cygwin DLL from memory.

Of course, even a reboot would probably not help in the scenario you
mentioned; if sshd is being run as a service, then it will *still* be
running after reboot.  In this case, maybe only a SIGTERM or SIGHUP to
the loaded Cygwin apps would work.

    Robert> Cygwin1.dll needs to provide an abstracted
    Robert> replace-file-on-reboot functionality, and the installing
    Robert> package stops as soon as such an occurence happens
    Robert> triggering another reboot...

    Robert> Weeeel, what would be really nice would be a hack to
    Robert> cygwin's delete-on-close queue, to allow the unix "delete
    Robert> this open file, now write a new file with the same name"
    Robert> functionality, with cygwin setting up a replace-on-reboot,
    Robert> and removing that replace-on-reboot if/when the file is
    Robert> actually closed and able to be done manually. _And_ for
    Robert> cygwin linked process, redirecting any opens to the queued
    Robert> replacement file :}.  That way the posix semantics would
    Robert> be present, for most files. However such a hack could be
    Robert> very difficult to do _the right way_... and I'm not going
    Robert> to get sidetracked by it :].

Now *that's* a feature that would be worth adding to cygwin1.dll.
However, I suspect it would be a bear to implement, though :-)

    Robert> Thank you. The developer list has spent a bunch of time
    Robert> tossing around various ideas - that was a synopsis of the
    Robert> critical issues that any cygwin hosted installer has to
    Robert> overcome. (Note that cygwin used to have a cygwin-hosted
    Robert> installer, and moved away from that post B20.1).

Yes, I remember B20.1 somewhat fondly.  I actually made my own CD-ROM
with a very crufty text-based installer (actually, just a Bourne shell
script that would set-up the mount points and unpack a few tar files,
including Andy Piper's Cygwin build of XEmacs.)  Worked great, still
have a copy of it somewhere in my office.

Ever since building this CD-ROM install for B20.1, I've wanted to
re-do it using Tcl/Tk.  Unfortunately, it's taken me nearly four years
to do it...

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
> 
>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
>     Robert> different shared memory region identifier, to prevent
>     Robert> crashes :}.
> 
> Just curious; can't we avoid a specially built version of cygwin1.dll
> by making sure that cygwin1.dll isn't loaded when the installer runs?
> Making a special verion of cygwin1.dll could add more confusion.
What if:
the irt cygwin1.dll is incompatible with the installed, running
cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
the irt uses?) results in a crash.
I covered ina different reply the mechanics of a different shared memory
identifier.

>     Robert> ok... how do you update that installer toolbox?
> 
> The installer toolbox (drat, I should have called it the IRT, for
> "installer run-time") would be updated only when:
> 
>     * a cygwin1.dll bug has been fixed that affects the installer
> 
>     * a cygwin1.dll feature has been added that is needed by a
>       newer version of the installer.
> 
> In either of these cases, a new self-extracting binary for the
> installer would be built which would include the updated installer
> toolbox.  Note that the installer toolbox, AKA installer run-time, is
> only used by the installer; the installed Cygwin would never use these
> tools.
K.

>     Robert> Unix allows the deletion and replacement of open files,
>     Robert> win32 doesn't.  Thats the root of the problems I'm
>     Robert> highlighting - so no, Linux is not as badly off as we are
>     Robert> :}.
> 
> OK, I didn't understand your original point.  Yes, I think the
> solution here is to make sure that the RPM packages should not
> included scripts that would exhibit this problem.
> 
>     Robert> Again, how do the users update the toolbox? Or do they
>     Robert> download a 5mb install for the toolbox when it needs
>     Robert> updating?
> 
> Users would not update the installer run-time, only the installer's
> maintainer.  Since the installer run-time would be included in the
> self-extracting installer (and would be delete automatically by the
> installer after it's completed its job), the users would never really
> have to know about it, or worry about updating it.  In fact, I believe
> that installers built with InstallShield work in this fashion; they
> can unpack a series of files to C:\WINDOWS\TEMP and run a second-stage
> installer from there.
>
> Regarding the size of the installer run-time, my current environment
> is 1.5M compressed.  Since the stub EXE that would be prepended to
> this archive to make it self-extracting would probably be only about
> 10-50KB, I'd guess that the self-extracting installer would not be
> much bigger than 1.5M.  While this makes it considerably bigger than
> the current setup.exe (~239K), it can still be downloaded in a
> reasonable amount of time (6.9 minutes @ 28.8Kbps, 3.6 minutes @
> 56Kbps.) The biggest files in the run-time are cygwin1.dll, rpm.exe,
> cygtk80.dll, and cygtcl80.dll.
OK. You might get a smaller size if they were stripped? (1.5 Mb
compressed _sounds_ big so I'm guessing at that.).
 
>     Robert> Uhmm, assuming the user actually knows whats going
>     Robert> on. Consider a user that is not the sysadmin of the
>     Robert> machine, and doesn't know that sshd is running. In theory,
>     Robert> yes with user cooperation, you can do this. In practice I
>     Robert> suspect that saying "we have installed a new version of
>     Robert> cygwin1.dll, to make it take effect reboot your machine"
>     Robert> will be less prone to support questions.
> 
> OK, how about adding two buttons on the dialog, "Retry" and "Reboot",
> making Reboot the default choice.  The dialog box can tell the user to
> shut down the Cygwin apps that were found and click on retry, or they
> press Enter and accept the default action, which would reboot the
> machine, clearing the loaded Cygwin DLL from memory.
Yes, thats good - however the reboot needs to use the replace on reboot
mechanism - see below.

> Of course, even a reboot would probably not help in the scenario you
> mentioned; if sshd is being run as a service, then it will *still* be
> running after reboot.  In this case, maybe only a SIGTERM or SIGHUP to
> the loaded Cygwin apps would work.
As long as you have permissions to shut them down :]. I can _assure_
you, given past experience, that users don't easily comprehend "login as
administrator, and set the service startup to manual, then eiether stop
the service and retry or reboot". Microsoft have had to release
technotes detailing how to do that for things like Exchange Server. A
good installer covers that base - and it's a uniquely win32 base
unfortunately.
 
>     Robert> be present, for most files. However such a hack could be
>     Robert> very difficult to do _the right way_... and I'm not going
>     Robert> to get sidetracked by it :].
> 
> Now *that's* a feature that would be worth adding to cygwin1.dll.
> However, I suspect it would be a bear to implement, though :-)
Yah. I'll skip for now :]
 
> 
> Ever since building this CD-ROM install for B20.1, I've wanted to
> re-do it using Tcl/Tk.  Unfortunately, it's taken me nearly four years
> to do it...
Finding time is not always easy is it! Still, it's sounding good.

As an aside, cygwin-the-distro to me is a lot closer to debian GNU/Linux
than Redhat GNU/Linux - the constantly evolving packages, with firm
policies on quality and responsibility. From that angle, I'd like to see
the current "run-setup every now and then, download the new stuff, and
watch it install" process remain, a


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[egor duda]

Hi!

Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:

RC> On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
>> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
>> 
>>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
>>     Robert> different shared memory region identifier, to prevent
>>     Robert> crashes :}.
>> 
>> Just curious; can't we avoid a specially built version of cygwin1.dll
>> by making sure that cygwin1.dll isn't loaded when the installer runs?
>> Making a special verion of cygwin1.dll could add more confusion.
RC> What if:
RC> the irt cygwin1.dll is incompatible with the installed, running
RC> cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
RC> the irt uses?) results in a crash.
RC> I covered ina different reply the mechanics of a different shared memory
RC> identifier.

if you run x:\some\temp\path\ash.exe and x:\some\temp\path\ contains
cygwin1.dll is _doesn't_ matter if any other program is running from
c:\cygwin\bin and using incompatible version of cygwin1.dll from
c:\cygwin\bin\, as long as you're taking care about shared memory
region name.

when x:\some\temp\path\ash.exe is calling some function from
cygwin1.dll, it's taken from the x:\some\temp\path\cygwin1.dll

>>     Robert> Uhmm, assuming the user actually knows whats going
>>     Robert> on. Consider a user that is not the sysadmin of the
>>     Robert> machine, and doesn't know that sshd is running. In theory,
>>     Robert> yes with user cooperation, you can do this. In practice I
>>     Robert> suspect that saying "we have installed a new version of
>>     Robert> cygwin1.dll, to make it take effect reboot your machine"
>>     Robert> will be less prone to support questions.
>> 
>> OK, how about adding two buttons on the dialog, "Retry" and "Reboot",
>> making Reboot the default choice.  The dialog box can tell the user to
>> shut down the Cygwin apps that were found and click on retry, or they
>> press Enter and accept the default action, which would reboot the
>> machine, clearing the loaded Cygwin DLL from memory.
RC> Yes, thats good - however the reboot needs to use the replace on reboot
RC> mechanism - see below.

well, this is an issue with _any_ installer, including current
setup.exe I can't see why we're paying so much attention in context of
"RPM installer". It's generic problem (probably) worth separate
discussion.

RC> As an aside, cygwin-the-distro to me is a lot closer to debian GNU/Linux
RC> than Redhat GNU/Linux - the constantly evolving packages, with firm
RC> policies on quality and responsibility. From that angle, I'd like to see
RC> the current "run-setup every now and then, download the new stuff, and
RC> watch it install" process remain, a

this will remain as it is currently (if i understand things
correctly). RPM is good for tracking dependencies, checking
installation integrity, signature verification etc. -- the issues
current setup doesn't address or partially address.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 27 Jul 2001 16:55:57 +0400, egor duda wrote:
> Hi!
> 
> Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
> 
> RC> On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
> >> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
> >> 
> >>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
> >>     Robert> different shared memory region identifier, to prevent
> >>     Robert> crashes :}.
> >> 
> >> Just curious; can't we avoid a specially built version of cygwin1.dll
> >> by making sure that cygwin1.dll isn't loaded when the installer runs?
> >> Making a special verion of cygwin1.dll could add more confusion.
> RC> What if:
> RC> the irt cygwin1.dll is incompatible with the installed, running
> RC> cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
> RC> the irt uses?) results in a crash.
> RC> I covered ina different reply the mechanics of a different shared memory
> RC> identifier.
> 
> if you run x:\some\temp\path\ash.exe and x:\some\temp\path\ contains
> cygwin1.dll is _doesn't_ matter if any other program is running from
> c:\cygwin\bin and using incompatible version of cygwin1.dll from
> c:\cygwin\bin\, as long as you're taking care about shared memory
> region name.

Yes - precisely my point :]. (Dario asked about avoiding having a
different shared memory region name).

> when x:\some\temp\path\ash.exe is calling some function from
> cygwin1.dll, it's taken from the x:\some\temp\path\cygwin1.dll
> 
> RC> Yes, thats good - however the reboot needs to use the replace on reboot
> RC> mechanism - see below.
> 
> well, this is an issue with _any_ installer, including current
> setup.exe I can't see why we're paying so much attention in context of
> "RPM installer". It's generic problem (probably) worth separate
> discussion.

And it's been discussed to some degree on the developers list. And we
came to the no-time conclusion :/. It is generic, yes...

> RC> As an aside, cygwin-the-distro to me is a lot closer to debian GNU/Linux
> RC> than Redhat GNU/Linux - the constantly evolving packages, with firm
> RC> policies on quality and responsibility. From that angle, I'd like to see
> RC> the current "run-setup every now and then, download the new stuff, and
> RC> watch it install" process remain, a
> 
> this will remain as it is currently (if i understand things
> correctly). RPM is good for tracking dependencies, checking
> installation integrity, signature verification etc. -- the issues
> current setup doesn't address or partially address.

Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
uses filepath+name rather than a feature). The point being that a
"rpmfind" database is then needed, rather than the current setup.exe (if
this or a simialr tcl/tk+rpm installer is adopted).

Rob

> 
> Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Borsenkow Andrej]

>
> Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
> uses filepath+name rather than a feature).

What do you mean? It is using both, if you call Provides: line a feature
list.

-andrej

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 27 Jul 2001 18:47:12 +0400, Borsenkow Andrej wrote:
> 
> >
> > Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
> > uses filepath+name rather than a feature).
> 
> What do you mean? It is using both, if you call Provides: line a feature
> list.

What version is that in? Excellent news regardless... thanks.
Rob

> -andrej
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Borsenkow Andrej]

Robert Collins wrote:

> On 27 Jul 2001 18:47:12 +0400, Borsenkow Andrej wrote:
> 
>>>Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
>>>uses filepath+name rather than a feature).
>>>
>>What do you mean? It is using both, if you call Provides: line a feature
>>list.
>>
> 
> What version is that in? Excellent news regardless... thanks.


4.x for sure, and those (fairly new) 3.x versions I remember (but here I 
am not completely sure).

-andrej

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[egor duda]

Hi!

Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:

RC> On 27 Jul 2001 16:55:57 +0400, egor duda wrote:
>> Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
>> RC> On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
>> >> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
>> >> 
>> >>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
>> >>     Robert> different shared memory region identifier, to prevent
>> >>     Robert> crashes :}.
>> >> 
>> >> Just curious; can't we avoid a specially built version of cygwin1.dll
>> >> by making sure that cygwin1.dll isn't loaded when the installer runs?
>> >> Making a special verion of cygwin1.dll could add more confusion.
>> RC> What if:
>> RC> the irt cygwin1.dll is incompatible with the installed, running
>> RC> cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
>> RC> the irt uses?) results in a crash.
>> RC> I covered ina different reply the mechanics of a different shared memory
>> RC> identifier.
>> 
>> if you run x:\some\temp\path\ash.exe and x:\some\temp\path\ contains
>> cygwin1.dll is _doesn't_ matter if any other program is running from
>> c:\cygwin\bin and using incompatible version of cygwin1.dll from
>> c:\cygwin\bin\, as long as you're taking care about shared memory
>> region name.

RC> Yes - precisely my point :]. (Dario asked about avoiding having a
RC> different shared memory region name).

No! he talked about custom-built dll. custom-built dll and different
shared region name are _different_ issues. You can make 2 normally
built dlls to have different shared area names. i use stock version
1.1.8 for debugging version 1.3.2. gdb uses 1.1.8, debugee uses 1.3.2.
they're running along nicely.

so, *If* you can guarantee that all applications during bootstrapping
are run from the single directory, you can make them not interfere
with other currently running cygwin applications.

[...]

>> this will remain as it is currently (if i understand things
>> correctly). RPM is good for tracking dependencies, checking
>> installation integrity, signature verification etc. -- the issues
>> current setup doesn't address or partially address.

RC> Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
RC> uses filepath+name rather than a feature).

it can use file name/package name/feature (with versioning, btw).

RC> The point being that a  "rpmfind" database is then needed, rather
RC> than the current setup.exe (if this or a simialr tcl/tk+rpm
RC> installer is adopted).

??? why? setup remains donwloading/bootstrapping tool. it could,
eventually, utilize something like rpmfind-generated index to help you
through downloading process.
Or we can leave setup as GUI front-end while having rpm-based
back-end, i.e. just merge tcl/tk installer interface functions into
setup.exe

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Robert Collins]

On 27 Jul 2001 19:18:34 +0400, egor duda wrote:
> Hi!
> 
> Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
> 
> RC> On 27 Jul 2001 16:55:57 +0400, egor duda wrote:
> >> Friday, 27 July, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
> >> RC> On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
> >> >> >>>>> "Robert" == Robert Collins <robert.collins@itdomain.com.au> writes:
> >> >> 
> >> >>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
> >> >>     Robert> different shared memory region identifier, to prevent
> >> >>     Robert> crashes :}.
> >> >> 
> >> >> Just curious; can't we avoid a specially built version of cygwin1.dll
> >> >> by making sure that cygwin1.dll isn't loaded when the installer runs?
> >> >> Making a special verion of cygwin1.dll could add more confusion.
> >> RC> What if:
> >> RC> the irt cygwin1.dll is incompatible with the installed, running
> >> RC> cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
> >> RC> the irt uses?) results in a crash.
> >> RC> I covered ina different reply the mechanics of a different shared memory
> >> RC> identifier.
> >> 
> >> if you run x:\some\temp\path\ash.exe and x:\some\temp\path\ contains
> >> cygwin1.dll is _doesn't_ matter if any other program is running from
> >> c:\cygwin\bin and using incompatible version of cygwin1.dll from
> >> c:\cygwin\bin\, as long as you're taking care about shared memory
> >> region name.
> 
> RC> Yes - precisely my point :]. (Dario asked about avoiding having a
> RC> different shared memory region name).
> 
> No! he talked about custom-built dll. custom-built dll and different
> shared region name are _different_ issues. You can make 2 normally
> built dlls to have different shared area names. i use stock version
> 1.1.8 for debugging version 1.3.2. gdb uses 1.1.8, debugee uses 1.3.2.
> they're running along nicely.

Uhmm, I'm bit unclear as to how you can change the shared memory region
with building a custom cygwin1.dll. 

> so, *If* you can guarantee that all applications during bootstrapping
> are run from the single directory, you can make them not interfere
> with other currently running cygwin applications.

Yes... I know and agree.

> [...]
> > 
> it can use file name/package name/feature (with versioning, btw).

Excellent - it's obviously come a ways since I last dug deep.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

Folks,

First off, I want to thank all of you for all the comments and
insight, it's clear that all of you have very good points to consider
regarding a Tcl/Tk GUI installer using cygwin1.dll.  Another thing
that's become clear to me is that my original design is lacking, and
must be reworked to accommodate as many of the excellent points all of
you have brought up.

Therefore, I'm going to review all the messages in this thread so that
every point brought up is considered, and incorporate these points in
a new design.  Once this redesign is complete (which hopefully should
only take a few days), I will post again to the mailing list,
hopefully to begin a second round of design review.  I expect the
resulting design will stand a better chance of actually working.

Again, I want to express my gratitude to all of you who took the time
to critique the design; I'm sure all of you, like myself, have regular
full-time jobs that must be attended to, making it difficult to find
time to spend on Cygwin.  I appreciate your efforts.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Jonadab the Unsightly One]

[replacing files on reboot]
# > well, this is an issue with _any_ installer, including current
# > setup.exe I can't see why we're paying so much attention in context of
# > "RPM installer". It's generic problem (probably) worth separate
# > discussion.
# 
# And it's been discussed to some degree on the developers list. And we
# came to the no-time conclusion :/. It is generic, yes...

The need to reboot when installing anything is just part
of the deal when you use Windows.  If you install a new
graphics library, you can't just restart X like in Unix,
and if you add a new TCP/IP gateway you can't just 
restart networking like in BeOS.  When you install 
something in Windows, you reboot.  Sometimes you have
to reboot twice, and in extreme cases thrice, but good 
design can keep it down to once.  

Note that I'm talking about 9x/Me here; dunno about NT.

I use Windows, and I like Windows, but it does have
some limitations.  If you really need the kind of 
24/7 uptime that demands no rebooting for installing
software, then IMO you need to look past Cygwin and 
consider some brand of kernel-and-all Unix system.  

-- 
Your font seems to be:    proportional     fixed
                                             ^
                                             |

(Fontmeter only accurate for about 90% of fonts.)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Charles Wilson]

Robert Collins wrote:
> ok... how do you update that installer toolbox?

As Dario said, you don't.  I just wanted to point out how pkgconfig and
glib-1.3 handle this.  I recently discovered (during my unsuccessful
attempts to build glib-1.3 using "new-style" tools (see recent postings
on binutils, automake, and libtool lists)) that recent gnome stuff like
glib-1.3.x no longer use the assortment of "*-config" scripts.  Instead,
they require a separate tool, called "pkg-config".  

Okay, but pkg-config depends on glib, and glib depends on pkg-config. 
so what they do, is ship an old, stable version of glib WITH the
pkg-config source.  pkg-config then automatically builds and links ONLY
to its included copy of glib-1.2.10.

(Side benefit: glib-1.2.10 is MUCH smaller and simpler than glib-1.3.x. 
Some *major* code bloat going on there, IMO...)

So, Dario's RPM-based install kit can ship with a nice stable
cygwin1.dll (taking care to provide the source for THAT version, so the
GPL is happy). Now, I'm not suggesting that he use 1.1.8 or (heaven
forbid) that he "strip down" to a special reduced-functionality "kernel"
like pkg-config does, but 1.3.2 is pretty good.  If ALL that is being
used in the install kit is RPM and sh, and perhaps awk and sed, it's
unlikely that those will tickle any serious bugs in this "old" version. 
His install kit can stay at 1.3.2 "forever" -- or until HE decides that
he needs to upgrade it.  His end users needn't worry about it.

> > Here's what should happen: the first stage installer detects a Cygwin
> > DLL conflict, and determines which currently running application(s)
> > have links to cygwin1.dll.  We present this list to the user, saying
> > "we've noticed the following Cygwin app(s) are running.  Before you
> > can continue with the installation, please close these apps down.
> > Re-run the installer after you've done this."  By asking the user to
> > shut down the apps, we accomplish two things: cygwin1.dll gets
> > unloaded, and we avoid the reboot.

Hmmm...if I run "ps" with a special cygwin1.dll that has a different
shared region name, will it see processes being run with the "real"
cygwin1.dll?  (I'd imagine so, but I haven't tried it myself, so I'm not
sure).

> Uhmm, assuming the user actually knows whats going on. Consider a user
> that is not the sysadmin of the machine, and doesn't know that sshd is
> running. In theory, yes with user cooperation, you can do this. In
> practice I suspect that saying "we have installed a new version of
> cygwin1.dll, to make it take effect reboot your machine" will be less
> prone to support questions.

Yeah, but we say "shut down all running cygwin applications before
running setup.exe"  How is our method any different than Dario's
proposed version?  (Actually, his is better because he says "Hey luser:
you've still got X and Y and Z cygwin-based programs running.  Shut 'em
down"

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Bernard Dautrevaux]

> -----Original Message-----
> From: Dario Alcocer [ mailto:alcocer@helixdigital.com ]
> Sent: Wednesday, July 25, 2001 11:08 PM
> To: cygwin@cygwin.com
> Cc: Bernard Dautrevaux
> Subject: RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
> 
> 
> >>>>> "Bernard" == Bernard Dautrevaux 
> <Dautrevaux@microprocess.com> writes:
> 
>     Bernard> Or as the installer user interface is tcl/tk-based, you
>     Bernard> can look at FreeWrap
>     Bernard> 
> ( http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html ). Its
>     Bernard> neat and works quite well; moreover the tcl/tk installer
>     Bernard> in this case do not NEED cygwin, so can unpack the basic
>     Bernard> bootstrap environment without any problem).
> 
> Yes, I guess this would work as well.  However, the main reason I
> didn't want eliminate the Cygwin DLL was that I wanted to use ash to
> run the RPM package post-install/pre-uninstall scripts with it.  I
> guess I could find a Win32 Bourne-compatible shell that didn't require
> Cygwin to replace ash, but that would still leave me looking for
> Win32-only ports of the other utilities that might be required by the
> scripts (e.g. awk, sed, cut, paste etc.)

I was not suggesting suppressing the cygwin1.dll, sh, etc... Just mentionned
that using FreeWrap you can get a self-contained executable that will
execute your TCL installer. This installer can then "extract" all the files
you need from the FreeWrapped executable. 

You can then wrap 
	The non-cygwin wish provided with FreeWrap
	Your TCL installer
	cygwin1.dll
	ash, awk, sed, cut, paste...
In one exe which will (under tcl control) create a temporary directory,
place cygwin1.dll et al. in it and then use this as your execution
environment for your installation. When installation is finished you then
can just remove this directory for cleaning this environment.
	
> 
> In the end, it just seemed simpler that, rather than trying to avoid
> including Cygwin in the installer (and miss out on all that
> functionality), I should instead find a way to use cygwin1.dll and
> avoid the pitfalls instead.  I decided on a two-stage install process;
> the first stage would check for a duplicate cygwin1.dll loaded in
> memory (and abort with a message if one was found), and the second
> stage would be the actual Tcl/Tk installer.

This first stage can in fact be done by the beginning of a FreeWrapped tcl
script. I think you should really look at what FreeWrap can do: it will not
just wrap a tcl script, but also all the needed auxiliary text or binary
files you need.

HTH,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Mark" == Stucky, Mark B UTRC <StuckyMB@utrc.utc.com> writes:

    Mark> You might also want to take a look at freeDelivery

Actually, RPM will handle the installation of Cygwin apps.  I only
need a self-extracting .ZIP file so that the minimum Cygwin programs
needed by the Tcl/Tk GUI installer can be packaged as one binary.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: SETUP WIZARD FOR CYGWIN?XFREE86

[egor duda]

Hi!

Tuesday, 24 July, 2001 Charles Wilson cwilson@ece.gatech.edu wrote:

CW> Port rpm to win32.  Not cygwin.

i can't see why "not cygwin". bootstrapping *is* a problem, but
honestly, it seems easier to me than mingw port of rpm.

cygwin1.dll is reasonably self-sufficient nowadays. i'm using
"minimalistic ssh client" which consists of 3 files: cygwin1.dll,
ssh.exe (from openssh) and small bat file which sets %HOME% before
staring ssh. everything's working perfectly either on wnt or w9x.
sure, rpm is more "system-dependent" than ssh, but anyway, i don't see
a big problem to create mounts (the only (?) cygwinism rpm really
needs) on the early stages of bootstrap.

if you're concerned about different versions of cygwin1.dll, take a
look at cygwin testsuite. there're no problems with testing new build of
cygwin1.dll while several programs based on the old one are running
in the same time on the same machine.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "egor" == egor duda <deo@logos-m.ru> writes:

    egor> Hi!  Tuesday, 24 July, 2001 Charles Wilson
    egor> cwilson@ece.gatech.edu wrote:

    CW> Port rpm to win32.  Not cygwin.

    egor> i can't see why "not cygwin". bootstrapping *is* a problem,
    egor> but honestly, it seems easier to me than mingw port of rpm.

    egor> cygwin1.dll is reasonably self-sufficient nowadays. i'm
    egor> using "minimalistic ssh client" which consists of 3 files:
    egor> cygwin1.dll, ssh.exe (from openssh) and small bat file which
    egor> sets %HOME% before staring ssh. everything's working
    egor> perfectly either on wnt or w9x.  sure, rpm is more
    egor> "system-dependent" than ssh, but anyway, i don't see a big
    egor> problem to create mounts (the only (?) cygwinism rpm really
    egor> needs) on the early stages of bootstrap.

    egor> if you're concerned about different versions of cygwin1.dll,
    egor> take a look at cygwin testsuite. there're no problems with
    egor> testing new build of cygwin1.dll while several programs
    egor> based on the old one are running in the same time on the
    egor> same machine.

Egor, it's very interesting that you mention this approach to
bootstrapping RPM.  I've in fact built an initial working version of a
Tcl/Tk GUI installer using the *exact* approach you mention, using a
small Cygwin bootstrap environment (rpm.exe, sh.exe, mount.exe
cygwin1.dll, and other necessary programs.)

The installation is performed in two steps:

1. Create the necessary directories and mounts, unpack rpm binary tar,
   then run 'rpm --initdb'

2. Run rpm to install RPM files.

All the install related tasks (cygwin.bat creation, installing bash
short-cut, running mkpasswd and mkgroup, etc.) are performed by RPM
post-install scripts.

Best part is, it actually *works*.  I've not completed all the work on
it (I've been too busy with several consulting gigs to spend more than
3-5 hours per week on it.)  However, I now have a staff member that's
tying up the loose ends and getting it ready for actual use (I plan on
using the Tcl/Tk installer in my consulting work.)  The main
limitation now is that there isn't a self-extracting mechanism worked
out yet that would create the bootstrap environment before launching
the Tcl/Tk GUI installer.  For my purposes, I was planning on creating
CDs with the necessary bootstrap environment pre-unpacked, so this
would only be an issue for trying to support a self-contained
network-based installer like the current setup.exe.  This is not an
insurmountable problem, so I expect to have something implemented for
this feature eventually.

Anyway, at some point I'd like to be able to offer it to the Cygwin
project.  Unfortunately, it's still very immature to be widely
released, which is why I had not suggested or mentioned it before.
Nevertheless, if any of you are interested in playing around with the
installer, I could put a CD-ROM .iso image (~13MB) up on my web site
eventually when the work is done (I hope to have a very rough first
release by the middle of August.)

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
Cygwin Ghostscript maintainer
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Charles Wilson]

Sounds cool, Dario.  How have your db and rpm ports been generated? 
Which versions are you using, db-3 and rpm-4, or db-2 and rpm-3 ?  Is db 
built as a dll, or as a static lib ?

BTW, for your purposes perhaps you could pack up your bootstrap 
environment into a self-extracting zip file ?

--Chuck

Dario Alcocer wrote:


> Egor, it's very interesting that you mention this approach to
> bootstrapping RPM.  I've in fact built an initial working version of a
> Tcl/Tk GUI installer using the *exact* approach you mention, using a
> small Cygwin bootstrap environment (rpm.exe, sh.exe, mount.exe
> cygwin1.dll, and other necessary programs.)
> 
> The installation is performed in two steps:
> 
> 1. Create the necessary directories and mounts, unpack rpm binary tar,
>    then run 'rpm --initdb'
> 
> 2. Run rpm to install RPM files.
> 
> All the install related tasks (cygwin.bat creation, installing bash
> short-cut, running mkpasswd and mkgroup, etc.) are performed by RPM
> post-install scripts.
> 
> Best part is, it actually *works*.  I've not completed all the work on
> it (I've been too busy with several consulting gigs to spend more than
> 3-5 hours per week on it.)  However, I now have a staff member that's
> tying up the loose ends and getting it ready for actual use (I plan on
> using the Tcl/Tk installer in my consulting work.)  The main
> limitation now is that there isn't a self-extracting mechanism worked
> out yet that would create the bootstrap environment before launching
> the Tcl/Tk GUI installer.  For my purposes, I was planning on creating
> CDs with the necessary bootstrap environment pre-unpacked, so this
> would only be an issue for trying to support a self-contained
> network-based installer like the current setup.exe.  This is not an
> insurmountable problem, so I expect to have something implemented for
> this feature eventually.
> 
> Anyway, at some point I'd like to be able to offer it to the Cygwin
> project.  Unfortunately, it's still very immature to be widely
> released, which is why I had not suggested or mentioned it before.
> Nevertheless, if any of you are interested in playing around with the
> installer, I could put a CD-ROM .iso image (~13MB) up on my web site
> eventually when the work is done (I hope to have a very rough first
> release by the middle of August.)




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Chuck" == Charles Wilson <cwilson@ece.gatech.edu> writes:

    Chuck> Sounds cool, Dario.  How have your db and rpm ports been
    Chuck> generated?

Yes, the ports are done.  Basically, I took the Project HeavyMoon[1]
patches for db-2/rpm-3 and reworked them slightly.  The only thing I
found so far is that find-requires needs to call cygcheck (instead of
ldd), but other than that, it seems to work fine.  Post-install and
pre-uninstall scripts work fine.

I had thought about submitting my db-2/rpm-3 ports as contributed
packages, but I didn't know how much interest there would be, given
that both are old versions.

    Chuck> Is db built as a dll, or as a static lib ?

Currently db is linked statically, but I suppose that a DLL should
work.

    Chuck> BTW, for your purposes perhaps you could pack up your
    Chuck> bootstrap environment into a self-extracting zip file ?

Yes, I think that would work fine.  I was thinking about looking for
an open-source/GPL solution, but I've not started looking yet.  If you
can point me to something, I'd definitely would look at it.

[1] - see http://www10.u-page.so-net.ne.jp/fa2/riue-s/index.html

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Rue. SATOH]

Hello.

Project HeavyMoon was moved to http://www.sixnine.net/cygwin/ ,
but I don't announced yet.

In < 15199.13076.290060.138271@coyote.priv.helixdigital.com >,
Dario Alcocer <alcocer@helixdigital.com> wrote:

alcocer> Yes, the ports are done.  Basically, I took the Project HeavyMoon[1]
alcocer> patches for db-2/rpm-3 and reworked them slightly.  
:
alcocer> Currently db is linked statically, but I suppose that a DLL should
alcocer> work.

I had built db-3.1.17 with DLLize patch.
If you want, please get from Project HeavyMoon.
My rpm port use some DLL(cygbz, cygdb, cygz) now.

And I had made tarball that include minimum environment and tools.

o ash
o mkgroup
o mkpasswd
o mount
o umount 
o rpm 
o rpm2cpio
o cygbz21.0.dll
o cygdb3.dll
o cygwin1.dll
o cygz.dll

This tarball is ftp://ftp.st.ryukoku.ac.jp/pub/ms-windows/HeavyMoon/instkit.tar.gz .

I think that we shall use this sequence to install.
I usually use this sequence for build to my cygwin environment that
all packages are managemented by rpm(Now, I don't use packages that
provided by cygwin.com).

1. extract minimum environment and tools(Ex. instkit.tar.gz).
2. mount / directory.
3. rpm --initdb
4. mkpasswd & mkgroup(optional)
5. install some rpm packages
   o termcap(DLLized)
   o zlib(DLLized)
   o ncurses(DLLized)
   o ash
   o info
   o grep
   o bash
   o bzip2(including DLLized bzip2 library)
   o db(DLLized)
   o popt
   o file
   o rpm

Why we use this sequence? Because rpm.exe depend cygz.dll,
cygbz21.0.dll and cygdb3.dll. rpm.exe use file.exe, sh.exe
and some tools too...

--
[ Rue. SATOH ] http://www.sixnine.net/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Dario Alcocer]

>>>>> "Rue" == Rue SATOH <rsato@ccs.co.jp> writes:

    Rue> Hello.
    Rue> Project HeavyMoon was moved to http://www.sixnine.net/cygwin/ ,
    Rue> but I don't announced yet.

Thanks for the information, I'll check out the new site soon.

    Rue> I had built db-3.1.17 with DLLize patch.
    Rue> If you want, please get from Project HeavyMoon.
    Rue> My rpm port use some DLL(cygbz, cygdb, cygz) now.

Great, I'll check out the port.  Do you have a src.rpm for RPM?  I'd
be interested in reviewing the *.patch files and the .spec file too.

    Rue> And I had made tarball that include minimum environment and tools.

    Rue> o ash
    Rue> o mkgroup
    Rue> o mkpasswd
    Rue> o mount
    Rue> o umount 
    Rue> o rpm 
    Rue> o rpm2cpio
    Rue> o cygbz21.0.dll
    Rue> o cygdb3.dll
    Rue> o cygwin1.dll
    Rue> o cygz.dll

    Rue> I think that we shall use this sequence to install.
    Rue> I usually use this sequence for build to my cygwin environment that
    Rue> all packages are managemented by rpm(Now, I don't use packages that
    Rue> provided by cygwin.com).

    Rue> 1. extract minimum environment and tools(Ex. instkit.tar.gz).
    Rue> 2. mount / directory.
    Rue> 3. rpm --initdb
    Rue> 4. mkpasswd & mkgroup(optional)

Actually, this could be done by a Cygwin-specific RPM package, one
that contains a post-install script that would create the /etc/passwd
and /etc/group files.

    Rue> 5. install some rpm packages
    Rue>    o termcap(DLLized)
    Rue>    o zlib(DLLized)
    Rue>    o ncurses(DLLized)
    Rue>    o ash
    Rue>    o info
    Rue>    o grep
    Rue>    o bash
    Rue>    o bzip2(including DLLized bzip2 library)
    Rue>    o db(DLLized)
    Rue>    o popt
    Rue>    o file
    Rue>    o rpm

    Rue> Why we use this sequence? Because rpm.exe depend cygz.dll,
    Rue> cygbz21.0.dll and cygdb3.dll. rpm.exe use file.exe, sh.exe
    Rue> and some tools too...

Yes, installation order does matter, but this is the same issue you
run into with the Linux version of RPM, so we're not really any worse
off.

-- 
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
alcocer@helixdigital.com -- http://www.helixdigital.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)

[Rue. SATOH]

Hello.

In < 15200.14971.630343.872301@coyote.priv.helixdigital.com >,
Dario Alcocer <alcocer@helixdigital.com> wrote: 

alcocer>     Rue> I had built db-3.1.17 with DLLize patch.
alcocer>     Rue> If you want, please get from Project HeavyMoon.
alcocer>     Rue> My rpm port use some DLL(cygbz, cygdb, cygz) now.
alcocer> 
alcocer> Great, I'll check out the port.  Do you have a src.rpm for RPM?  I'd
alcocer> be interested in reviewing the *.patch files and the .spec file too.

Yes I do. I made and distributed src.rpm. But it doesn't include db's
source code. This src.rpm include only *.patch and .spec file(It is
called 'nosrc.rpm').

alcocer>     Rue> 1. extract minimum environment and tools(Ex. instkit.tar.gz).
alcocer>     Rue> 2. mount / directory.
alcocer>     Rue> 3. rpm --initdb
alcocer>     Rue> 4. mkpasswd & mkgroup(optional)
alcocer> 
alcocer> Actually, this could be done by a Cygwin-specific RPM package, one
alcocer> that contains a post-install script that would create the /etc/passwd
alcocer> and /etc/group files.

Why? Why do you create /etc/passwd and /etc/group in post-install
script? I afraid of upgrade of rpm packages. If you do 'rpm -Uvh rpm-package.rpm',
/etc/passwd and /etc/group is overwritten by post-install script.

--
[ Rue. SATOH ] rsato@ccs.co.jp

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/