X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-5.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <50622016.6060208@cornell.edu>
References: <5061D0B4 DOT 40601 AT cs DOT utoronto DOT ca>	<5061E4CA DOT 5090708 AT cornell DOT edu>	<CAM-A7MBGCjdDv+iehp2As5wDh+UbpmJt6wzp1edh6-7Ey=05Eg AT mail DOT gmail DOT com>	<50622016 DOT 6060208 AT cornell DOT edu>
Date: Wed, 26 Sep 2012 09:03:46 -0700
Message-ID: <CAM-A7MASMproZM54pQhHMykBwuGGOfSjxTimo4ThZzWWcHi7oA@mail.gmail.com>
Subject: Re: Unwanted texlive invasion
From: Wynfield Henman <wynfield AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

 In my humble opinion cygwin should be open to improvement and, we
should keep cygwin's purpose as a base system, which is as full, and
as easy, and as close to a *nix environment as possible.

On Tue, Sep 25, 2012 at 2:20 PM, Ken Brown <kbrown AT cornell DOT edu> wrote:
......... snipped
>
>> I don't agree.  The solution should not be to install an unnecessary
>> package and waste space and complicate by having to check order in the
>> PATH variable.
>
> People who install programs that are not provided by Cygwin have to expect
> to set PATH appropriately, including checking the order of the paths.

Nonsense.  cygwin does behave, has behaved, and should operate in as
should as a base for *nix environment, applications, and tools.
Forcing such minutiae as, what goes where in PATH, is not an elegant
solution.  A temporary work-around it is, but not a good final
solution.

>
>> It would be better that a.) installation scripts check for the
>> existence of the necessary commands first and not brute force the
>> installation or warning that the cygwin port of it be installed.
>
> For the issue being discussed in this thread (the gnuplot dependency on
> texlive-collection-basic), the necessary command *is* /usr/bin/mktexlsr.
> Running the mktexlsr provided by the native TeX Live distribution will not
> do the job (which is to make the files installed in /usr/share/texmf-dist accessible to tex).

Yes, it would do the job.  Note that 'mktexslr' is not a TexLive
function, at least not in my setup.  Assuming that mktexslr has been
developed properly it will find the TexLive required code since it is
in PATH, else it would print a 'req'd  name.xxx not found.  Then the
user can do what has to be done.

Now the real issue was flagged by the texlive dependency, but the main
issue is all dependencies in general and how to handle them the best.
We shouldn't be myoptic, but look to solutions that would cover all
cases, not just a single case.  I believe we want cygwin to be a
robust, easy to use, yet powerful tool.

>> It may also be desirable, to have setup use a list of packages to NOT
>> install, regardless of any dependencies.
>
> I don't think setup.exe should make it quite that easy for people to
> circumvent dependencies.

On the contrary we make cygwin easy to use and free to users to
customize their system.  I suppose you're worried that could cause a
lot of problems, which it could if applied naively, but that would be
the user's problem and such features could easy display a warning, and
a user at his own disgression could set an option <if this feature was
added> to not display the warning every time and carry on setup
processing just as the user chose.

  But maybe something like the Debian "equivs"
> facility would be useful (see http://www.tug.org/texlive/debian.html for a
> discussion of this in the context of TeX Live).

This might be a good idea. I'm not familiar with it, but again it is
desired to have a general solution for all depencies and not just
Texlive based ones.

> As usual, it's easy to come up with ideas for enhancing setup.exe; but
>
>   http://cygwin.com/acronyms/#SHTDI
>
Yes, of course it takes someone and resources to implement it.  But,
ideas should be always welcome to those who are so valuable and do
work on setup.  It's improvements lately are extremely appreciate by
me.

> Ken
>
Wynfield

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple