Charles Wilson wrote:
> On 5/27/2010 9:49 PM, Earnie wrote:
>> Charles Wilson wrote:
>>> So, you WANT rebaseall, a particular script provided by a particular
>>> package, which expects specific behavior and options from an executable
>>> that is provided by *that same package*, to use whatever random
>>> executable that happens to have the same name which it might find in the
>>> PATH? Especially when that PATH is *not* the normal path most MSYS
>>> users are familiar with after they launch a "normal" shell via msys.bat?
>> But if I didn't install to / the rebase executable wouldn't be found in
>> /bin anyway.
> Wait. (a) Why wouldn't you, and (b) are the binary *msys* packages
> uploaded to sourceware expected to work properly if they are NOT
> installed in the expected directory?
Yes, they should work properly if not installed in the expected
directory. I know there are a few that expect to find their files by
default in /usr/share but those are exceptions easily worked around.
> I know that the msys-autotool packages will have a very hard time if
> they are not installed into MSYS "/" -- since they will look explicitly
> for their share/autoconf/*, share/automakeN.NN/*, and share/aclocal/
> files under / == /usr.
IIRC there is an environment variable that can be set to control where
these are located.
> Even the mingw-autotool packages will have trouble if they are installed
> somewhere other than /mingw ('course, it doesn't matter where that
> /mingw is physically located: C:\MinGW or D:\my-backup-mingw\)
Since autotool is mostly scripts I would not have thought to have a
autotool-mingw package installed. But again IIRC there is an
environment variable to control where to look.
> I know that msys executables are no longer *required* to be installed
> into the /bin where msys-1.0.dll lives, but...even on linux, if you
> download an RPM that is supposed to be installed in /usr, and somehow
> manage to install it in /usr/local -- you'll be very lucky if it works
> at all. If you want to install an RPM somewhere else, you're expected
> to download the SRPM and rebuild.
Ack, auto-packaging. But I am very much a believer in build it your
self which tends to overcome the obstacles of prepackaged binary
releases. I have though come to trust apt-get enough to use it on my
Ubuntu installations. I never liked RPM syntax enough to learn it.
>>> I'm sorry, Earnie, but that's...not wise. It's ASKING for trouble.
>> In either scenario there are issues and assuming /bin isn't correct
>> either. Perhaps a better scenario would be to set PATH to the directory
>> name of argv.
> Suppose instead of ACTUALLY hardcoding PATH=/bin, the rebaseall script
> were, in the source package, named rebaseall.in, and contained
> "PATH=@bindir@". That what, when rebuilt with a different --prefix, it
> would work.
Yes, this would work up to a point. That point being one of ``make
install prefix=/my/depot/release/directory''. I loathe DESTDIR and
changing prefix at install time is not supposed to disturb the build
> Your idea of "use the directory of $0" would be ok, too.
Isn't this more like what other distributed package scripts do?
> But...you're arguing about the way an upstream application is coded --
> it's not as if I wrote rebaseall, or was proposing a patch for
> msys-1.0.dll itself.
> While we can certainly patch the rebase package for MSYS's purposes --
> and I *have*, simply because I wanted to use "dash" instead of "ash",
> since the former is more actively maintained upstream -- this seems to
> be a departure from the way most MSYS packages are treated. I've just
> been describing how the pre-existing, upstream package operates, and why
> it does so...not how my spiffy brand-new written-just-for-msys tool is
Ack. I don't expect you to change it unless you had written it. :)
>>> The rebase.exe provided by the Microsoft SDK doesn't accept the -T
>>> option. rebaseall uses it. That's one reason why PATH is explicitly set
>>> to /bin. Also, remember that the recommended sequence is:
>> Ok, an understandable reason but I still think there are better ways to
>> accomplish the goal.
> Again, this is an upstream behavior. Usually we don't *require* rewrites
> of upstream code, unless explicitly *buggy* on msys. That isn't the case
> here: if I installed rebase on cygwin into /usr/local, it'd not work
> there either. (SO, unless there is a *requirement* that rebaseall work
> if installed somewhere other than / == /usr, your suggestions are "gee
> it'd be nice if", not "this is broken because".)
>>> launch a dash shell
>>> * dash doesn't read the bash startup files, so your PATH is
>>> probably not what you're used to, in "regular" bash. Plus,
>>> you haven't run msys.bat, so all the PATH shenanigans it performs
>>> don't happen either.
>> So it doesn't read /etc/profile or ~/.profile? I knew there was some
>> reason I used bash instead of the default cygwin shell.
> dash reads both /etc/profile and ~/.profile for *login* shells. It
> always reads the file whose path is specified in the environment
> variable ENV. (So, if no ENV is set and dash is NOT started as a login
> shell, then *no* startup files are read at all). However, so if
> rebase's README said 'start dash as a login shell: dash -l' then that'd
> be one thing, but it doesn't. It says:
> 1. shutdown all MSYS processes
> 2. start dash (do not use bash or rxvt)
> 3. execute /bin/rebaseall (in the dash window)
> However, I'm not actually sure that's in error. Many times, people's
> login scripts start resident programs; mine launches ssh-agent -- which
> will break rebaseall because it expects, and verifies, that NO msys
> processes are running except for dash itself.
>> If the tool is installed at / yes, but if the tool is installed in
>> /usr/local it will be an issue.
> So, two questions: (1) is it *required* that pre-compiled MSYS packages
> must operate correctly if installed somewhere other than their
> compiled-in --prefix? (2) is it *required* that packages which we
> provide pre-compiled for MSYS, when RE-compiled from source and
> installed using a different --prefix must operate correctly?
1) *required*, no.
2) *required*, yes. This should be true regardless if it is for MSYS or
some other system especially if it is GPL since the GNU Coding Standards
should have been followed.
> Right now, rebase violates both. Personally, I think #1 is a fool's
> game. Now, #2...is another question. Most well-behavior packages obey
> it, but the upstream rebase package does not. It can be patched to do
> so, of course -- and THAT patch might actually be accepted upstream
> (most of the other MSYS mods -- e.g. explicitly using dash rather than
> ash -- wouldn't).
So, the upstream package needs a fix.
> As far as a proposed patch, I could see either
> and creating the real rebaseall script from rebaseall.in at configure, or
> PATH=$(cd $tp2&& pwd)
> to always use rebase.exe from the same directory in which rebaseall
> itself is found. This would facilitate testing an uninstalled rebaseall
> (*) -- except that it would not be able to "find" sed, grep, sort..., so
> we'd need
> PATH=$(cd $tp2&& pwd):@bindir@
PATH=$(cd $tp2&& pwd):@bindir@...
> anyway. (If somebody didn't install *our* sed, grep, and sort -bin
> packages into /, the God help 'em).
Ack. That goes with what is stated in the README.
> (*) You still have to shutdown all other MSYS applications, exit your
> normal shell, launch a new dash shell, then explicitly invoke
> /path/to/my/builddir/rebaseall...so this isn't really all THAT helpful.
>>> Oddly, however, nobody in six years on cygwin has ever found it
>>> necessary to use *some other rebase* than the one *shipped with the
>>> rebaseall* script.
>> Ok, I'll take a look. Maybe because most users would use the setup.exe
>> program to install it and it would end up in the /bin directory is the
>> reason no one has complained.
> Sure. Cygwin distributes precompiled binaries in a "install as directed,
> or don't blame us, WJM" fashion. Traditionally, *msys* packages are
> provided the same way; in the days of msys-dtk-1.0.1 + updates, nobody
> would've expected the coreutils or perl update "overlay" to work
> correctly if it were unpacked in /usr/local/ rather than /. It MIGHT
> have worked -- but if it didn't the answer would have been "Don't Do That."
> The core MinGW packages like gcc, binutils, etc, of course, are
> different (I exclude the mingw autotool packages, for reasons that now
> resemble a dead horse).
Probably smell like one too. ;p