search

dskvr / opkg

Automatically exported from code.google.com/p/opkg
0 stars 0 forks source link

Some deb packages are installed with no files #137

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I have created multiple debian packages. They are all fine except for the 
attached one.

The package installs without producing any warnings or errors. But after 
installation no new files appear on the system. When I query opkg for installed 
files for the package it also returns no results:

    opkg files libgbm1
    Package libgbm1 (10.2.0~rc4-2wld) is installed on root and has the following files:

Few packages from official Debian repo also have the same behavior. For example 
this one: 
http://ftp.us.debian.org/debian/pool/main/k/keyutils/libkeyutils1_1.5.5-3_amd64.
deb

I'm using opkg 0.2.2 built from source with no extra patches. The system is 
x86_64 GNU/Linux.

Original issue reported on code.google.com by dima@golovin.in on 9 Jul 2014 at 10:00

Attachments:

GoogleCodeExporter commented 8 years ago 
I don't think the support for official Debian packages in opkg is very good.

What command did you use to create your packages? Most opkg users build 
packages using 'opkg-build' from opkg-utils or an equivalent tool. I'd suggest 
trying to build packages using this.

Original comment by paul.betafive on 9 Jul 2014 at 10:16

GoogleCodeExporter commented 8 years ago 
I used `debuild` to build my packages. After being rebuilt with `opkg-build` 
everything installs fine.

Original comment by dima@golovin.in on 9 Jul 2014 at 12:29

GoogleCodeExporter commented 8 years ago 
Ok, I'm going to mark this as "won't fix". opkg should focus on small code size 
and memory usage rather than trying to support foreign package formats.

Original comment by paul.betafive on 9 Jul 2014 at 2:43

GoogleCodeExporter commented 8 years ago 
Is it really foreign package format? I thought it is just the same.

Original comment by dima@golovin.in on 9 Jul 2014 at 4:30

GoogleCodeExporter commented 8 years ago 
On 9 July 2014 20:31, Patrick 'P. J.' McDermott <pj+google@pehjota.net> wrote:
> [I'm replying on the list because I don't have a Google account to
> reply to the bug report.]

No problem here, I'll copy replies into the bugtracker so everyone can see them

>
> On 2014-07-09 06:00, opkg@googlecode.com wrote:
>> Status: New
>> Owner: ----
>> Labels: Type-Defect Priority-Medium
>>
>> New issue 137 by d...@golovin.in: Some deb packages are installed with no 
files
>> http://code.google.com/p/opkg/issues/detail?id=137
>>
>> I have created multiple debian packages. They are all fine except for the 
attached one.
>>
>> The package installs without producing any warnings or errors. But after 
installation no new files appear on the system. When I query opkg for installed 
files for the package it also returns no results:
>>
>>     opkg files libgbm1
>>     Package libgbm1 (10.2.0~rc4-2wld) is installed on root and has the 
following files:
>>
>> Few packages from official Debian repo also have the same behavior. For 
example this one: 
http://ftp.us.debian.org/debian/pool/main/k/keyutils/libkeyutils1_1.5.5-3_amd64.
deb
>>
>> I'm using opkg 0.2.2 built from source with no extra patches. The system is 
x86_64 GNU/Linux.
>>
>> Attachments:
>>     libgbm1_10.2.0~rc4-2wld_amd64.deb  46.3 KB
>
> The issue is that newer Debian packages are being built with xz
> compression for the data archive member:
>
>     $ ar t libkeyutils1_1.5.5-3_amd64.deb
>     debian-binary
>     control.tar.gz
>     data.tar.xz

Thanks for this. I didn't have time to look into this myself, glad someone else 
did! I now understand what's going wrong.

>
> opkg (at least version 0.2.x) only supports gzip compression.  opkg
> 0.3.x (with libarchive) might support other compression algorithms – I
> haven't checked.

Regardless of the compression format, opkg looks for a file named 'data.tar.gz' 
in the package archive. This would have to be changed as well as the supported 
compression formats expanded to support anything else.

This is why I'm marking this as WONTFIX - Debian are free to make whatever 
decisions they want on their package formats and these decisions may not be 
appropriate for an embedded Linux system. I don't want to say that we'll follow 
whatever changed dpkg makes.

I may be able to add a compile time option to enable support for this in opkg 
0.3.x. That way, the default build can remain small but if the user wants 
support for a wider range of compression formats they may enable it at the cost 
of a potentially larger executable. This is especially important for anyone who 
wants to statically link opkg against libarchive.

>
> To build with gzip compression, either run dpkg-buildpackage or debuild
> with "-Zgzip" or put the following in debian/source/options:
>
>     compression = "gzip"

Or rebuild the package with opkg-build.

>
> If libarchive supports the other compression algorithms, I think this
> bug can be marked as fixed.
>

As stated above, this won't be supported by a default opkg build but it may be 
possible to add a compile time option to enable such support.

Original comment by paul.betafive on 10 Jul 2014 at 1:55

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I think this should be reopened or maybe I should submit a new issue with more 
clear name and description.

The problem is that the package still installs and shows in installed packages 
list even if it is not installed at all.
Expected behavior: package not installed, error message displayed.

In pkg_extract.c there is an error message "Failed to extract data.tar.gz from 
package '%s'.\n", but I have never seen it displayed (possibly a bug?).

Original comment by dima@golovin.in on 18 Jul 2014 at 7:16

GoogleCodeExporter commented 8 years ago 
The problem there is:

commit a1b131545aeb67349b066c1eece7e9bae903574c
Author: graham.gower <graham.gower@e8e0d7a0-c8d9-11dd-a880-a1081c7ac358>
Date:   Fri Dec 4 01:00:02 2009 +0000

    Ignore extraction errors, for now. Requested by Koen.

    As opkg has never failed from these errors in the past, many recipes in
    OpenEmbedded have come to rely on this behaviour. So proceed regardless of
    extraction errors for now, to give the OE folks a chance to fix broken
    packages first.

    git-svn-id: http://opkg.googlecode.com/svn/trunk@445 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358

diff --git a/libbb/unarchive.c b/libbb/unarchive.c
index c3630b0..31c76d2 100644
--- a/libbb/unarchive.c
+++ b/libbb/unarchive.c
@@ -313,6 +313,7 @@ unarchive(FILE *src_stream, FILE *out_stream,
                        buffer = extract_archive(src_stream, out_stream,
                                        file_entry, extract_function,
                                        prefix, err);
+                       *err = 0; /* XXX: ignore extraction errors */
                        if (*err) {
                                free_headers(file_entry);
                                break;

Unfortunately, this is how opkg has behaved since end-2009. The problem is 
fixed on the master branch (and so will be fixed in 0.3.0 when released). I 
don't want to fix this on the 0.2.x branch as it could cause problems for users 
who expect the current behaviour (and probably don't even know that they have 
silently failing packages).

Original comment by paul.betafive on 18 Jul 2014 at 10:56