libc error in Warpin scripts

Sir:

I am getting libc errors in various Warpin scripts, where they are
looking for libc of different versions. What the bitch? Are of them
are installed in \OS2\dll. Why cannot these scripts check to see if
they are loadable, instead of whatever they are checking? I am pointing
to Klibccfg.dll's Warpin script and tesseract203base's Warpin script.
Actually the second pointed me falsely to the first before I realized
that they were wanting the libc files themselves. So what do I need to
add to Klibccfg to make this work, if anything?
--
Bill
Thanks a Million!

On Fri, 9 May 2008 04:41:56 UTC, "William L. Hartzell"
<wlhartzell@tx.rr.com> wrote:
[color=blue]
> Sir:
>
> I am getting libc errors in various Warpin scripts, where they are
> looking for libc of different versions. What the bitch? Are of them
> are installed in \OS2\dll. Why cannot these scripts check to see if
> they are loadable, instead of whatever they are checking? I am pointing
> to Klibccfg.dll's Warpin script and tesseract203base's Warpin script.
> Actually the second pointed me falsely to the first before I realized
> that they were wanting the libc files themselves. So what do I need to
> add to Klibccfg to make this work, if anything?[/color]

They are probably wanting you to install libc with WarpIN. They don't
need to check that way -- instead they could actually check for the
required DLL. That's what the WarpIN installer for PMMail 3.0 does.

--
Expert Consulting for OS/2 and eComStation
[url]http://www.blondeguy.com[/url]

Sir:

Neil Waldhauer wrote:[color=blue]
> On Fri, 9 May 2008 04:41:56 UTC, "William L. Hartzell"
> <wlhartzell@tx.rr.com> wrote:
>[color=green]
>> Sir:
>>
>> I am getting libc errors in various Warpin scripts, where they are
>> looking for libc of different versions. What the bitch? Are of them
>> are installed in \OS2\dll. Why cannot these scripts check to see if
>> they are loadable, instead of whatever they are checking? I am pointing
>> to Klibccfg.dll's Warpin script and tesseract203base's Warpin script.
>> Actually the second pointed me falsely to the first before I realized
>> that they were wanting the libc files themselves. So what do I need to
>> add to Klibccfg to make this work, if anything?[/color]
>
> They are probably wanting you to install libc with WarpIN. They don't
> need to check that way -- instead they could actually check for the
> required DLL. That's what the WarpIN installer for PMMail 3.0 does.
>[/color]
Given the memory issue with Warpin's database, this is a sorry
requirement. Now if Warpin loaded its database into private memory,
then the problem with too many entries causing depletion of shared
memory would not arise? However, if one holds his jaw just right,
wpiview will extract the files, thanks.
--
Bill
Thanks a Million!

On 05/13/08 02:41 pm, William L. Hartzell wrote:[color=blue]
> Sir:
>
> Neil Waldhauer wrote:[color=green]
>> On Fri, 9 May 2008 04:41:56 UTC, "William L. Hartzell"
>> <wlhartzell@tx.rr.com> wrote:
>>[color=darkred]
>>> Sir:
>>>
>>> I am getting libc errors in various Warpin scripts, where they are
>>> looking for libc of different versions. What the bitch? Are of them
>>> are installed in \OS2\dll. Why cannot these scripts check to see if
>>> they are loadable, instead of whatever they are checking? I am
>>> pointing to Klibccfg.dll's Warpin script and tesseract203base's
>>> Warpin script. Actually the second pointed me falsely to the first
>>> before I realized that they were wanting the libc files themselves.
>>> So what do I need to add to Klibccfg to make this work, if anything?[/color]
>>
>> They are probably wanting you to install libc with WarpIN. They don't
>> need to check that way -- instead they could actually check for the
>> required DLL. That's what the WarpIN installer for PMMail 3.0 does.
>>[/color]
> Given the memory issue with Warpin's database, this is a sorry
> requirement. Now if Warpin loaded its database into private memory, then
> the problem with too many entries causing depletion of shared memory
> would not arise? However, if one holds his jaw just right, wpiview will
> extract the files, thanks.[/color]

This has been discussed before (the libc problem) and really instead of
it being a warpin problem it is more of a script writer problem. As Niel
says, the warpin packages can just look for the actual DLL.
Dave

On Wed, 14 May 2008 00:14:32 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:
[color=blue]
> This has been discussed before (the libc problem) and really instead of
> it being a warpin problem it is more of a script writer problem. As Niel
> says, the warpin packages can just look for the actual DLL.[/color]

Yep. As a possible workaround there was suggested to add an "Install
anyway"
type of confirmation box in case a dependend package is not present. As
far
as I can see, nobody has added this to

[url]http://xtracker.xworkplace.org/index.php?project=3[/url]

Should I do ?



--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
[url]http://www.s-t.de[/url]
Please remove all characters left of the "R" in my email address

Sir:

Ruediger Ihle wrote:[color=blue]
> On Wed, 14 May 2008 00:14:32 UTC, Dave Yeo <dave.r.yeo@gmail.com> wrote:
>[color=green]
>> This has been discussed before (the libc problem) and really instead of
>> it being a warpin problem it is more of a script writer problem. As Niel
>> says, the warpin packages can just look for the actual DLL.[/color]
>
> Yep. As a possible workaround there was suggested to add an "Install
> anyway"
> type of confirmation box in case a dependend package is not present. As
> far
> as I can see, nobody has added this to
>
> [url]http://xtracker.xworkplace.org/index.php?project=3[/url]
>
> Should I do ?
>
>
>[/color]
Please, any work-around including not searching the Warpin database
would be welcomed.
--
Bill
Thanks a Million!

On Wed, 14 May 2008 05:03:30 +0000 (UTC), Ruediger Ihle <NOSPAM_R.Ihle@S-t.De>
wrote:
[color=blue][color=green]
>> This has been discussed before (the libc problem) and really instead of
>> it being a warpin problem it is more of a script writer problem. As Niel
>> says, the warpin packages can just look for the actual DLL.[/color]
>
> Yep. As a possible workaround there was suggested to add an "Install
> anyway"
> type of confirmation box in case a dependend package is not present. As
> far
> as I can see, nobody has added this to
>
> [url]http://xtracker.xworkplace.org/index.php?project=3[/url]
>
> Should I do ?[/color]

It will get marked as "won't fix" if you do, so I wouldn't bother.

On Wed, 14 May 2008 15:10:06 UTC, Paul Ratcliffe
<abuse@orac12.clara34.co56.uk78> wrote:
[color=blue]
> It will get marked as "won't fix"[/color]

Why ?



--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
[url]http://www.s-t.de[/url]
Please remove all characters left of the "R" in my email address

On Wed, 14 May 2008 16:21:26 +0000 (UTC), Ruediger Ihle <NOSPAM_R.Ihle@S-t.De>
wrote:
[color=blue][color=green]
>> It will get marked as "won't fix"[/color]
>
> Why ?[/color]

Because it has knock on implications. What if something needs to know the
path where the DLLs are supposed to be installed? You can't have a list of
prerequisites and then choose to ignore some/all of them. It is a
contradiction in terms.

[color=blue]
> What if something needs to know the path where the DLLs are supposed
> to be installed? You can't have a list of prerequisites and then
> choose to ignore some/all of them. It is a contradiction in terms.[/color]

That's with your terms added, "something needs to know", implying "run"
instead of just "install". One can distinguish between a warning message
with "install" and a fatal error message with "run".

What if I just want to have SOME.DLL from THIS.WPI, while THIS.WPI is
requiring THAT.WPI in order to run? Your case is the most likely one,
but there's no need to deny any other options. Including installing
THIS.WPI before installing THAT.WPI, for whatever reason.

And, trivial: what if THIS.WPI requires THAT.WPI, and THAT.WPI does
require an installed THIS.WPI package?



---

Sir:

Mie wrote:[color=blue][color=green]
> > What if something needs to know the path where the DLLs are supposed
> > to be installed? You can't have a list of prerequisites and then
> > choose to ignore some/all of them. It is a contradiction in terms.[/color]
>
> That's with your terms added, "something needs to know", implying "run"
> instead of just "install". One can distinguish between a warning message
> with "install" and a fatal error message with "run".
>
> What if I just want to have SOME.DLL from THIS.WPI, while THIS.WPI is
> requiring THAT.WPI in order to run? Your case is the most likely one,
> but there's no need to deny any other options. Including installing
> THIS.WPI before installing THAT.WPI, for whatever reason.
>
> And, trivial: what if THIS.WPI requires THAT.WPI, and THAT.WPI does
> require an installed THIS.WPI package?
>[/color]

The out to this inanity is the fact that wpi is a bz2 file. It can be
unarchived with WPIview utility. Paul is ignoring the fact that the
prerequisites exist, the installer script is badly written, and there
exist no path within Warpin around this problem that the user can take,
except exiting and doing as I suggest above. There are not too many wpi
scripts that actually add something to the registry and create complex
desktop folders. The same WPIview utility allows one to look at the
script and manually execute the script, if required. But this rare kind
of script IS just when having a USER by-pass to the prerequisites would
be nice.
--
Bill
Thanks a Million!

On Wed, 14 May 2008 19:08:51 UTC, Paul Ratcliffe
<abuse@orac12.clara34.co56.uk78> wrote:
[color=blue]
> What if something needs to know the path where the DLLs are
> supposed to be installed?[/color]

Then fail "hard" when this dependency (correct me if I'm wrong,
but I guess you are talking about a macro resolution of type
$(vendor\application\package)) is actually needed. Treat the
non-existence of a package listed in a "REQUIRES" keyword as
warning on which the user has to agree actively.

If I look at the script of the package that triggered this
thread I see the following:

<PCK INDEX=1
PACKAGEID="GoogleCode\Tesseract\Base\2\0\3"
TITLE="Tesseract including English language data"
TARGET="$(WARPIN_DEFAULTTOOLSPATH)\tesseract"
REQUIRES="netlabs.org\kLIBC\LIBC 0.6 Runtime\0\6\3\0"
...

There is no further reference to LIBC in the rest of the script.
Of course you can say that this is a script error and that the
creator should not use "REQUIRES" in this case, however having
a message poping up that says "Hey, I need LIBC but I don't think
it's installed" would be nicer than just mention this in the
README (Who reads READMEs ?). Especially, since there appear to
be a lot of packages out there, that do it this way. Also it adds
the freedom to the user to decide to install the dependent package
later.


[color=blue]
> You can't have a list of prerequisites and then choose to
> ignore some/all of them. It is a contradiction in terms.[/color]

Users of software are poeple, not machines. The usage of the
"REQUIRES" keyword is probably something widely "misunderstood"
among install package creators. But given the goal of WarpIN
to be an easy-to-use general purpose installer, I think it
should adapt to some degree.

It keeps the user's frustration down, avoids the need for 3rd
party tools to manipulate the archives (I'd say that the pure
existence of the WPIview utility is a sign for something going
wrong) and it prevents you from being the target of critics
about WarpIN not working correctly.



--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
[url]http://www.s-t.de[/url]
Please remove all characters left of the "R" in my email address

On May 14, 2:08 pm, Paul Ratcliffe <ab...@orac12.clara34.co56.uk78>
wrote:[color=blue]
> On Wed, 14 May 2008 16:21:26 +0000 (UTC), Ruediger Ihle <NOSPAM_R.I...@S-t.De>
> wrote:
>[color=green][color=darkred]
> >> It will get marked as "won't fix"[/color][/color]
>[color=green]
> > Why ?[/color]
>
> Because it has knock on implications. What if something needs to know the
> path where the DLLs are supposed to be installed? You can't have a list of
> prerequisites and then choose to ignore some/all of them. It is a
> contradiction in terms.[/color]

Paul, I understand what you are saying. However, there are going to
be instances bypassing a prerequisite may appear to be necessary.

example: The latest version of said program is two years old. It
uses a Warpin script for installatiion. It requires another Warpin
package already be installed before the installation will allow one to
continue. At that time two years ago, that package, whether it
consisted of dlls, system components, etc... was only available by a
Warpin install. The programmer who wrote the Warpin script used the
REQUIRE function in the Warpin script for who knows what reason.
Maybe he wanted to insure that the required components were already
installed. Less headache he has to deal with (people complaining that
his program does not work, crash, or dealing with false bug reports
due to the components not be already installed to the system). Since
then, the dlls or system components are now included with the
continually improving operating system (eCS).

Today, the user wants to install the program. It is the latest with
nothing else he considers as good or is readily available. He goes to
install said program on his eCS 2.0 system. Low and behold, it won't
install, because it says another Warpin script package is required.

What is that person to do.

1. Don't install because he can't install a program he desires or
needs. He knows the required components are already included with the
operating system. If he assumes the components are already found on
his system and they are not, then he must assume the responsibility
for his action if he were given the open to continue.
2. Try to find the required Warpin package. He has to hope it is
still available somewhere. What if it is not? If the package still
exists and he installs the package, he may be installing dlls or
system components to different locations that already now come with
the operating system. Now he duplicates. Duplicates in different
locations can cause problems. Remember what happened with the dlls
that came with Warpin and eCS originally. Different locations.
3. Use a program like ViewWPI to extract the files and try to install
manually. He has to then hope he gets everything right. If it is a
large program, odds are, he may not. Remember, this person may be
only a user who may not understand technical things. To him or her,
Warpin has been the greatest thing since Apple Pie because it has
always be hassle free installation. That is, until this issue popped
up. Warpin has sure made my life easier when it comes to installing
and removing programs.

I understand, the REQUIRED function is added by the programmer to
protect the user and himself. However, time goes on and things change.

So, the big question is, what is a person to do when a situation such
as this or similar is encountered.

On May 18, 5:47 pm, dwg...@swbell.net wrote:[color=blue]
> On May 14, 2:08 pm, Paul Ratcliffe <ab...@orac12.clara34.co56.uk78>
> wrote:
>[color=green]
> > On Wed, 14 May 2008 16:21:26 +0000 (UTC), Ruediger Ihle <NOSPAM_R.I...@S-t.De>
> > wrote:[/color]
>[color=green][color=darkred]
> > >> It will get marked as "won't fix"[/color][/color]
>[color=green][color=darkred]
> > > Why ?[/color][/color]
>[color=green]
> > Because it has knock on implications. What if something needs to know the
> > path where the DLLs are supposed to be installed? You can't have a list of
> > prerequisites and then choose to ignore some/all of them. It is a
> > contradiction in terms.[/color]
>
> So, the big question is, what is a person to do when a situation such
> as this or similar is encountered.[/color]

Pretend you added the "Continue at own risk" option. Possibly
something like the following could be done:

Selecting this option would bring up another page listing 4 options.

All 4 selections must be selected before continuing.

Selections:

1st. selection: I, the user, acknowledge that I am violating the
safety protocols set in place by the developer of this program and
the developers of Warpin.

2nd selection: I acknowledge that I can damage my system to an
unknown extent.

3rd selection: I acknowledge that I am only to blame and not the
programmer of this installation program and not the developer(s) of
the Warpin

4th selection: I have been duely warned and chose to continue

Once all four are selected, a Continue button becomes available.

In <Bd1D8ggkpXsj-pn2-zxhdRihqDJrs@Tobias>, on 05/15/2008
at 06:37 AM, "Ruediger Ihle" <NOSPAM_R.Ihle@S-t.De> said:

Hi,
[color=blue]
>Then fail "hard" when this dependency (correct me if I'm wrong, but I
>guess you are talking about a macro resolution of type
>$(vendor\application\package)) is actually needed. Treat the
>non-existence of a package listed in a "REQUIRES" keyword as warning on
>which the user has to agree actively.[/color]

I mostly agree with Paul on this. WarpIN is doing what the script
designer asked it too. The designer is making the assumption that libc is
always installed by WarpIN. This to too restrictive an assumption from my
POV.

There are other ways for the WarpIN script to check for the existance of
libc.

While it might be nice if WarpIN provided REXX exits for these kinds of
checks, this is not going to happen unless someone steps up and writes the
code and works with Paul to get an agreement to integrate the changes.

Allowing REQUIRES to be overridden is likey to cause more problems than it
will solve.

FWIW, if someone really needs to override something in a WarpIN script,
it's usually trivial to do so.

envwic
wic foo.wpi -X
edit foo.wis with fooedit or your favorite editor
wic foo.wpi -s foo.wis

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net> MR2/ICE 3.00 beta 11pre11 #10183
eCS/Warp/DIY/14.103a_W4 [url]www.scoug.com[/url] irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

Steven Levine wrote:[color=blue]
> In <Bd1D8ggkpXsj-pn2-zxhdRihqDJrs@Tobias>, on 05/15/2008
> at 06:37 AM, "Ruediger Ihle" <NOSPAM_R.Ihle@S-t.De> said:
>
> Hi,
>
>[color=green]
>>Then fail "hard" when this dependency (correct me if I'm wrong, but I
>>guess you are talking about a macro resolution of type
>>$(vendor\application\package)) is actually needed. Treat the
>>non-existence of a package listed in a "REQUIRES" keyword as warning on
>>which the user has to agree actively.[/color]
>
>
> I mostly agree with Paul on this. WarpIN is doing what the script
> designer asked it too.[/color]

Or the designer didn't understand what he was asking for.

The designer is making the assumption that libc is[color=blue]
> always installed by WarpIN. This to too restrictive an assumption from my
> POV.
>
> There are other ways for the WarpIN script to check for the existance of
> libc.
>
> While it might be nice if WarpIN provided REXX exits for these kinds of
> checks, this is not going to happen unless someone steps up and writes the
> code and works with Paul to get an agreement to integrate the changes.
>[/color]
....

On Mon, 19 May 2008 21:29:41 UTC, Steven Levine
<steve53@earthlink.bogus.net> wrote:

Hi Steven,
[color=blue]
> I mostly agree with Paul on this. WarpIN is doing what the script
> designer asked it too. The designer is making the assumption that libc is
> always installed by WarpIN. This to too restrictive an assumption from my
> POV.[/color]

Probably yes. But that rises the question, why several script creators
make the same (too restrictive) assumption and what can be done that
this is avoided in the future.

[color=blue]
> There are other ways for the WarpIN script to check for the existance of
> libc.[/color]

They are way too complicated for unexperienced installation creators.

[color=blue]
> Allowing REQUIRES to be overridden is likey to cause more problems than it
> will solve.[/color]

You mean on deinstalling ? Does WarpIN maintain a reference count or a
list
of packages that reference a dependent packages ?

Quote from WarpIN docs:

WPI_PROG.INF> When a package ID is specified, WarpIN will query the user

WPI_PROG.INF> computer's global database for the specified package.
WPI_PROG.INF> If that package is not installed or too old, WarpIN will
WPI_PROG.INF> give the user a warning message.

IMHO, that does not imply that the whole installation is aborted...

[color=blue]
> FWIW, if someone really needs to override something in a WarpIN script,
> it's usually trivial to do so.[/color]

Sure, but if this becomes necessary for every second program you want
to install, it gets annoying.



--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
[url]http://www.s-t.de[/url]
Please remove all characters left of the "R" in my email address