LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Bug in makepkg and symlinks with blanks in filename? (https://www.linuxquestions.org/questions/slackware-14/bug-in-makepkg-and-symlinks-with-blanks-in-filename-4175480597/)

DarkVision 10-22-2013 09:15 AM

Quote:

Originally Posted by ruario (Post 5050261)
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 (Post 5050361)
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 (Post 5050248)
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 (Post 5050248)

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 (Post 5050431)
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 (Post 5050431)
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 (Post 5050431)
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 (Post 5050442)
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 (Post 5061732)
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.


All times are GMT -5. The time now is 03:26 AM.