Packaging questions

Packaging questions

[Gary Thomas]

I'm [still] trying to set up a package for Amanda.  I'd like
the end result to match how it's done on other systems, e.g.
my desktop Fedora box.  However, this layout is causing some
QA errors which I don't know how to fix, e.g.

ERROR: QA Issue: non debug package contains .debug directory: amanda path 
/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so
ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: amanda path 
'/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'

I understand the first one but don't know the workaround.  How
do I tell bitbake that the directory /usr/lib/perl/5.14.2/auto/Amanda/MainLoop
contains executable code (and that's OK)?

The second issue I think is one of philosophy.  The symbolic link
is important to the package - how can I set this up to be OK?

Thanks for any pointers

Note: of course there are many of each of these classes of errors,
this is just a representative example.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Packaging questions

[Burton, Ross]

On 24 July 2013 14:56, Gary Thomas <gary@mlbassoc.com> wrote:
> I'm [still] trying to set up a package for Amanda.  I'd like
> the end result to match how it's done on other systems, e.g.
> my desktop Fedora box.  However, this layout is causing some
> QA errors which I don't know how to fix, e.g.
>
> ERROR: QA Issue: non debug package contains .debug directory: amanda path
> /work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so

This is resolved by fiddling with your FILES lines, the problem being
that PN is packaging that entire tree when it should be split up.
$PN-dbg collects files before $PN so you can add something like
"$(libdir)/perl/*/auto/Amanda/*/.debug" to FILES_$PN-dbg and $PN will
continue to take the rest.

> ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
> amanda path
> '/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'

I'm curious, what does the symlink point to?  It's possible that we
can refine the check to reduce the number of false positives, because
this is a fairly common one that needs to be skipped.

You can skip this QA test by setting INSANE_SKIP.  In this case,
INSANE_SKIP_${PN} = "dev-so" (you can identify the tag to use by
looking through classes/insane.bbclass for the error message).

Ross

Re: Packaging questions

[Gary Thomas]

On 2013-07-24 08:12, Burton, Ross wrote:
> On 24 July 2013 14:56, Gary Thomas <gary@mlbassoc.com> wrote:
>> I'm [still] trying to set up a package for Amanda.  I'd like
>> the end result to match how it's done on other systems, e.g.
>> my desktop Fedora box.  However, this layout is causing some
>> QA errors which I don't know how to fix, e.g.
>>
>> ERROR: QA Issue: non debug package contains .debug directory: amanda path
>> /work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so
>
> This is resolved by fiddling with your FILES lines, the problem being
> that PN is packaging that entire tree when it should be split up.
> $PN-dbg collects files before $PN so you can add something like
> "$(libdir)/perl/*/auto/Amanda/*/.debug" to FILES_$PN-dbg and $PN will
> continue to take the rest.

Thanks, this worked a treat.

>
>> ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>> amanda path
>> '/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
>
> I'm curious, what does the symlink point to?  It's possible that we
> can refine the check to reduce the number of false positives, because
> this is a fairly common one that needs to be skipped.

The .so symlink points to a fully qualified library, e.g.
-rwxr-xr-x 1 gthomas gthomas 1383729 Jul 24 06:35 libamanda-3.3.3.so
lrwxrwxrwx 1 gthomas gthomas      18 Jul 24 06:35 libamanda.so -> libamanda-3.3.3.so

The problem seems to be that this is the unqualified .so name and not a
version qualified name like 'libamanda.so.3'.  The package isn't building
the version qualified names, just the fully unqualified one.

>
> You can skip this QA test by setting INSANE_SKIP.  In this case,
> INSANE_SKIP_${PN} = "dev-so" (you can identify the tag to use by
> looking through classes/insane.bbclass for the error message).
>
> Ross
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Packaging questions

[Burton, Ross]

On 24 July 2013 15:30, Gary Thomas <gary@mlbassoc.com> wrote:
>>> ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>>> amanda path
>>>
>>> '/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
>>
>>
>> I'm curious, what does the symlink point to?  It's possible that we
>> can refine the check to reduce the number of false positives, because
>> this is a fairly common one that needs to be skipped.
>
>
> The .so symlink points to a fully qualified library, e.g.
> -rwxr-xr-x 1 gthomas gthomas 1383729 Jul 24 06:35 libamanda-3.3.3.so
> lrwxrwxrwx 1 gthomas gthomas      18 Jul 24 06:35 libamanda.so ->
> libamanda-3.3.3.so
>
> The problem seems to be that this is the unqualified .so name and not a
> version qualified name like 'libamanda.so.3'.  The package isn't building
> the version qualified names, just the fully unqualified one.
>
>
>>
>> You can skip this QA test by setting INSANE_SKIP.  In this case,
>> INSANE_SKIP_${PN} = "dev-so" (you can identify the tag to use by
>> looking through classes/insane.bbclass for the error message).

So that's not the pattern that the test was designed for (not that
it's actually implementing that design).  I'm sure Amanda developers
have a reason for this, but the presence of a .so symlink in a non-dev
package is enough to trip this test, so INSANE_SKIP is the best thing
to do.

Ross

Re: Packaging questions

[Gary Thomas]

On 2013-07-24 08:38, Burton, Ross wrote:
> On 24 July 2013 15:30, Gary Thomas <gary@mlbassoc.com> wrote:
>>>> ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>>>> amanda path
>>>>
>>>> '/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
>>>
>>>
>>> I'm curious, what does the symlink point to?  It's possible that we
>>> can refine the check to reduce the number of false positives, because
>>> this is a fairly common one that needs to be skipped.
>>
>>
>> The .so symlink points to a fully qualified library, e.g.
>> -rwxr-xr-x 1 gthomas gthomas 1383729 Jul 24 06:35 libamanda-3.3.3.so
>> lrwxrwxrwx 1 gthomas gthomas      18 Jul 24 06:35 libamanda.so ->
>> libamanda-3.3.3.so
>>
>> The problem seems to be that this is the unqualified .so name and not a
>> version qualified name like 'libamanda.so.3'.  The package isn't building
>> the version qualified names, just the fully unqualified one.
>>
>>
>>>
>>> You can skip this QA test by setting INSANE_SKIP.  In this case,
>>> INSANE_SKIP_${PN} = "dev-so" (you can identify the tag to use by
>>> looking through classes/insane.bbclass for the error message).
>
> So that's not the pattern that the test was designed for (not that
> it's actually implementing that design).  I'm sure Amanda developers
> have a reason for this, but the presence of a .so symlink in a non-dev
> package is enough to trip this test, so INSANE_SKIP is the best thing
> to do.

One final packaging question.  In my build I have these files:
   /etc/amanda/
   /etc/amanda/MyConfig/
   /etc/amanda/MyConfig/tapelist
   /etc/amanda/MyConfig/disklist
   /etc/amanda/MyConfig/amanda.conf

I want the /etc/amanda/MyConfig to be packaged separately in "amanda-demo" package.
   PACKAGES += " ${PN}-demo "
   FILES_${PN}-demo += " \
		 /etc/amanda/MyConfig/ \
		 /amanda \
   "
   FILES_${PN} += "${libdir} \
	    ${libexecdir}/amanda/* \
	    /var/amanda \
	    /etc/amanda \
   "

Sadly, the /etc/amanda/MyConfig tree is ending up in the main package.  How
can I stratify it the way I want?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Packaging questions

[Burton, Ross]

On 26 July 2013 16:43, Gary Thomas <gary@mlbassoc.com> wrote:
> One final packaging question.  In my build I have these files:
>   /etc/amanda/
>   /etc/amanda/MyConfig/
>   /etc/amanda/MyConfig/tapelist
>   /etc/amanda/MyConfig/disklist
>   /etc/amanda/MyConfig/amanda.conf
>
> I want the /etc/amanda/MyConfig to be packaged separately in "amanda-demo"
> package.
>   PACKAGES += " ${PN}-demo "
>   FILES_${PN}-demo += " \
>                  /etc/amanda/MyConfig/ \
>                  /amanda \
>   "
>   FILES_${PN} += "${libdir} \
>             ${libexecdir}/amanda/* \
>             /var/amanda \
>             /etc/amanda \
>   "
>
> Sadly, the /etc/amanda/MyConfig tree is ending up in the main package.  How
> can I stratify it the way I want?

Various things interacting explain this.  Package takes files in the
order that they appear in PACKAGES, so by using += you're *appending*
amanda-demo to PACKAGES, so it's at the end.  FILES_$PN defaults to a
long list of "useful" paths, including ${sysconfdir}.

So, two options, both of which will work:

1) prepend amanda-demo to PACKAGES, so it gets to take files first. =+
is the prepend operator.
2) Change FILES_$PN to explictly set the entire value instead of
appending the default, then you can leave out $sysconfdir.

Ross

Re: Packaging questions

[Gary Thomas]

On 2013-07-26 09:52, Burton, Ross wrote:
> On 26 July 2013 16:43, Gary Thomas <gary@mlbassoc.com> wrote:
>> One final packaging question.  In my build I have these files:
>>    /etc/amanda/
>>    /etc/amanda/MyConfig/
>>    /etc/amanda/MyConfig/tapelist
>>    /etc/amanda/MyConfig/disklist
>>    /etc/amanda/MyConfig/amanda.conf
>>
>> I want the /etc/amanda/MyConfig to be packaged separately in "amanda-demo"
>> package.
>>    PACKAGES += " ${PN}-demo "
>>    FILES_${PN}-demo += " \
>>                   /etc/amanda/MyConfig/ \
>>                   /amanda \
>>    "
>>    FILES_${PN} += "${libdir} \
>>              ${libexecdir}/amanda/* \
>>              /var/amanda \
>>              /etc/amanda \
>>    "
>>
>> Sadly, the /etc/amanda/MyConfig tree is ending up in the main package.  How
>> can I stratify it the way I want?
>
> Various things interacting explain this.  Package takes files in the
> order that they appear in PACKAGES, so by using += you're *appending*
> amanda-demo to PACKAGES, so it's at the end.  FILES_$PN defaults to a
> long list of "useful" paths, including ${sysconfdir}.
>
> So, two options, both of which will work:
>
> 1) prepend amanda-demo to PACKAGES, so it gets to take files first. =+
> is the prepend operator.
> 2) Change FILES_$PN to explictly set the entire value instead of
> appending the default, then you can leave out $sysconfdir.

Option #1 is perfect and does just what I want, thanks!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------