[SOLVED] Bug in makepkg and symlinks with blanks in filename?

DarkVision · 10-22-2013, 09:15 AM

Quote:

Originally Posted by ruario

Additionally with 1,550 views to this thread thus far, I'd be surprised if one or more of the SBo team haven't seen it as well, so they can keep an eye on new submissions.

So there is no need to fix it, anyone already knows about it :-)

Really... in about one year no one would remember this thread. This is something really rare but has the possibility to delete existing files from other packages. Just because of that i would welcome something like a warning... i would simply check if LINKGOESIN/LINKNAMEIS does exist in the package while creating the doinst.sh script. If not something went wrong. Just a reminder to the developers. Then they can decide what to do. This would not break anything...

My scripts will simply throw out a warning for now so i don't get hit by that anymore, no matter how the developers or makepkg will handle that in the future.

ruario · 10-22-2013, 09:32 AM

Quote:

Originally Posted by DarkVision

So there is no need to fix it, anyone already knows about it :-)

Nah, I am not saying that. I am saying it is OK for now (because it is not common and the main parties are aware of the issue), so now let's just wait for after 14.1 to see what volkerdi decides to do.

Lennie · 10-22-2013, 11:54 AM

Quote:

Originally Posted by GazL

Sure about that are you?

Code:

gazl@ws1:/tmp$ mkdir wibble
gazl@ws1:/tmp$ cd wibble
gazl@ws1:/tmp/wibble$ mkdir wobble
gazl@ws1:/tmp/wibble$ echo "plop" > wobble/bobble.txt
gazl@ws1:/tmp/wibble$ ln -sf wobble link
gazl@ws1:/tmp/wibble$ ls -lR
.:
total 0
drwxr-xr-x 2 gazl users 60 Oct 22 09:26 wobble
lrwxrwxrwx 1 gazl users  6 Oct 22 09:27 link -> wobble

./wobble:
total 4
-rw-r--r-- 1 gazl users 5 Oct 22 09:26 bobble.txt
gazl@ws1:/tmp/wibble$ rm -rf link
gazl@ws1:/tmp/wibble$ ls -lR
.:
total 0
drwxr-xr-x 2 gazl users 60 Oct 22 09:26 wobble

./wobble:
total 4
-rw-r--r-- 1 gazl users 5 Oct 22 09:26 bobble.txt
gazl@ws1:/tmp/wibble$

If you meant to illustrate what I said about the danger of 'rm -rf symlink/', you forgot the trailing /. That's when it becomes dangerous.

Quote:

Originally Posted by GazL

I believe that other packaging systems handle this sort of thing by throwing out packaging conflict errors, aborting the package install and requiring the end user to resolve them manually.

That's what I think is the most responsible approach, especially for a distro that is not meant for newbies.

GazL · 10-22-2013, 12:08 PM

Quote:

Originally Posted by Lennie

If you meant to illustrate what I said about the danger of 'rm -rf symlink/', you forgot the trailing /. That's when it becomes dangerous.

Ahh, yes, my mistake. apologies. The really weird thing about that rm -rf symlink/ is that it gets rid of the contents of the directory linked too, but neither the link or the directory linked too are removed, effectively it appears to treat it as a rm -rf link/* which is just insanely risky behavior. Do all UNIX do this, or is this peculiar to GNU rm?

ruario · 10-22-2013, 12:48 PM

Quote:

Originally Posted by Lennie

If you meant to illustrate what I said about the danger of 'rm -rf symlink/', you forgot the trailing /. That's when it becomes dangerous.

As I said earlier, the shell script conversion code would never produce a line like that anyway.

Quote:

Originally Posted by Lennie

That's what I think is the most responsible approach, especially for a distro that is not meant for newbies.

If a distro is meant for experienced users (or those that desire to be), then they do not need to be protected. People learn by making mistakes.

GazL · 10-22-2013, 01:07 PM

Quote:

Originally Posted by GazL

Do all UNIX do this, or is this peculiar to GNU rm?

To answer my own question. No they don't.

Can't see anything in the POSIX spec that suggests that a symlink specified as a command-line parameter should be treated as anything other than a file (whether or not it has a / on the end) and unlink()ed

Also, a quick test on my OpenBSD box and it doesn't display this brain-dead behaviour. This seems to be something the GNU guys have dreamed up, but didn't bother documenting. No wonder I was caught by surprise on that one.

ruario · 11-10-2013, 02:08 AM

If these kinds of improvements and fixes are something that is being considered, then now might be a good time to introduce them to -current following the recent release of 14.1, so as to give the maximum time to find any issues prior to the next Slackware release.

DarkVision · 10-01-2015, 10:57 PM

Quote:

Originally Posted by ruario

If these kinds of improvements and fixes are something that is being considered, then now might be a good time to introduce them to -current following the recent release of 14.1, so as to give the maximum time to find any issues prior to the next Slackware release.

Quote:

Thu Oct 1 21:21:36 UTC 2015
a/pkgtools-14.2-noarch-1.txz: Upgraded.
Patched makepkg and removepkg to support spaces in symlinks. Spaces in file
and directory names also work, so support should be complete.

So after two years this issue has been resolved

For the affected package i solved this issue a while ago by simply not using symlinks at all. This will take some more diskspace but would also speed uppackage handling.

Anyway... solved.