public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com
Subject: Re: Native symlinks and setup.exe
Date: Tue, 04 Oct 2016 21:20:00 -0000	[thread overview]
Message-ID: <66dbf3c5-a3d4-a04a-30e8-805750f36a1f@redhat.com> (raw)
In-Reply-To: <DD849478-5A57-441D-B6C8-6A1488E80FA0@solidrocksystems.com>


[-- Attachment #1.1: Type: text/plain, Size: 1612 bytes --]

On 10/04/2016 03:53 PM, Vince Rice wrote:
>>> Obviously, a political discussion is required, to decide whether it is
>>> ok, as is, or if a change in package logic would have benefits.

The easiest way to have the discussion would be to write a patch,
instead of debating about different behaviors but then expecting others
to do the work.

> I don’t see that changing. And, as already noted, setup isn’t a Cygwin program,
> so it knows (and cares) nothing about cygwin environment variables.

setup.exe has its own untar'ing code (it is NOT forking tar, since one
of the packages setup.exe has to install is tar, and it would be a
chicken-and-egg problem if setup always forked out to a tar program if
it can't first untar the tarball containing tar).  But while setup.exe
apparently does NOT currently honor the CYGWIN environment variable with
regards to how its untar'ring code should behave on symlinks, there's
nothing that prevents you from writing a patch to teach it to do so, and
perhaps that patch can even share some of the existing code for
cygwin1.dll so that you aren't writing it from scratch.  It should
already be clear that code exists in setup.exe that handles symlinks in
tarballs - all that this thread is complaining about is that the code
doesn't do it the way that cygwin1.dll does it.  But someone has to
write such a patch, and preferably someone that cares enough to be
bothered by the current behavior (I don't, so it won't be me writing it).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2016-10-04 21:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-01 18:49 Gene Pavlovsky
2016-10-01 21:56 ` Vlado
2016-10-02  6:27   ` Herbert Stocker
2016-10-02 11:48 ` Thorsten Kampe
2016-10-02 23:35   ` Gene Pavlovsky
2016-10-03 18:26     ` Thorsten Kampe
2016-10-04  6:57       ` Gene Pavlovsky
2016-10-04  8:15         ` Vlado
2016-10-04 20:42           ` Gene Pavlovsky
2016-10-04 19:21         ` Gerrit Haase
2016-10-04 20:54           ` Gene Pavlovsky
2016-10-04 21:04             ` Vince Rice
2016-10-04 21:20               ` Eric Blake [this message]
2016-10-04 23:15                 ` Gene Pavlovsky
2016-10-05  3:03                   ` Gene Pavlovsky
2016-10-04 19:39       ` Linda Walsh
2016-10-02 20:08 ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66dbf3c5-a3d4-a04a-30e8-805750f36a1f@redhat.com \
    --to=eblake@redhat.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).