Opkg overwrites dir-symlink with dir without -force-overwrite

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install the perl package, which puts in place a /usr/lib/perl/5.8 symlink 
to /usr/lib/perl/5.8.8.
2. Create a recipe which installs a file into a directory /usr/lib/perl/5.8/.
3. Install the package from step 2 into the rootfs along with step 1.

What is the expected output? What do you see instead?

/usr/lib/perl/5.8 becomes a directory.  Opkg should not overwrite the 
symlink with a directory from another package unless -force-overwrite is 
enabled.  It should error out, since this is obviously a packaging bug.

What version of the product are you using? On what operating system?

Ran into it with rev 197 of opkg svn doing builds out of an OE-like 
bitbake-based buildsystem (MontaVista Linux 6).

Please provide any additional information below.

Original issue reported on code.google.com by kerg...@gmail.com on 17 Nov 2009 at 3:44

[GoogleCodeExporter]

Take a look in unarchive.c: extract_archive().

Something like the following (untested) patch may do what you want, but its 
likely to leave parts of the package on the 
system. The current unarchive mess does not pass errors up the call tree, 
making it problematic to exit gracefully.

diff --git a/libbb/unarchive.c b/libbb/unarchive.c
index 5e9c13a..4598765 100644
--- a/libbb/unarchive.c
+++ b/libbb/unarchive.c
@@ -150,7 +150,10 @@ char *extract_archive(FILE *src_stream, FILE *out_stream, 
const file_header_t *f
        stat_res = lstat (full_name, &oldfile);
        if (stat_res == 0) { /* The file already exists */
            if ((function & extract_unconditional) || (oldfile.st_mtime < file_entry->mtime)) {
-               if (!S_ISDIR(oldfile.st_mode)) {
+               if (S_ISLNK(oldfile.st_mode)) {
+                   error_msg_and_die("%s: Not overwriting symlink %s with directory",
+                           __FUNCTION__, file_entry->name);
+               } else if (!S_ISDIR(oldfile.st_mode)) {
                    unlink(full_name); /* Directories might not be empty etc */
                }
            } else {

Original comment by graham.g...@gmail.com on 23 Nov 2009 at 12:03

[GoogleCodeExporter]

Ugh, that sucks.  Thanks for taking a look, I'll play with that patch.  Any 
long term plans 
to resolve the archive mess, out of curiosity?

Original comment by kerg...@gmail.com on 30 Nov 2009 at 4:54

[GoogleCodeExporter]

I recently added an error parameter to the unarchive.c functions to pass errors 
up the call stack so extraction errors will ensure 
early exit with a message now. Unwinding installation of a package may need to 
be rethought, because it cannot currently 
unwind with errors after a certain point (any extraction errors cause crap to 
be left on the system). So adding something like the 
above patch probably wouldn't make the situation worse in that regard - at 
least your perl package wouldn't get broken.

The --force-overwrite option sets a non global variable conf->force_overwrite. 
unarchive.c doesn't have access to this currently. 
I'd like to make the conf struct global so that this file (and others) can 
access config file and command line parameters. And also 
so that we're not passing a conf pointer to almost every function in opkg.

Long term, libbb could use an update from busybox' current stable release. The 
unarchiving code in busybox has undergone a 
major design change and its new interface would actually make things a lot 
nicer to implement what you are asking. But it 
doesn't really fit with how opkg works right now. Opkg needs a lot more work 
first, otherwise bolting an updated libbb on the 
side will inevitably just result in more work later.

So, unarchive/unzip may not be the best, but it works enough to identify and 
allow fixes for a bunch of design problems 
elsewhere in the code. That will be a priority over importing a new libbb.

Original comment by graham.g...@gmail.com on 30 Nov 2009 at 8:04

[GoogleCodeExporter]

Understood.  Thanks again :)

Original comment by kerg...@gmail.com on 2 Dec 2009 at 3:12

[GoogleCodeExporter]

I'm looking at removing unzip/unarchive and replacing with the use of 
libarchive which is well maintained and should handle everything a lot better. 
Therefore I'm not going to fix anything within those functions now.

Original comment by paul.betafive on 18 Sep 2013 at 1:25

• Changed state: WontFix