This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unwanted texlive invasion


 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@cornell.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]