[Buildroot] Bizarre things on the allyespackageconfig build

[Buildroot] Bizarre things on the allyespackageconfig build

[Thomas Petazzoni]

Hello,

Following the allyespackageconfig, I did explore the generated
output/target filesystem, and noticed a number of bizarre things that
probably should be fixed:

 * There is a usr/argus directory, which contains just an empty
   'archive' directory. Doesn't seem to make much sense. Probably
   something to fix in the argus package.

 * There is a usr/arm-buildroot-linux-gnueabi directory, which contains
   just a 'bin' subdirectory, which contains ar, as, ld, nm, etc.

   $ ls usr/arm-buildroot-linux-gnueabi/bin/
   ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  strip

   That's a strange installation location for binutils.

 * There a usr/IDcheck.sh script. It comes from the LTP testsuite.

 * There a bunch of libraries that don't have the executable bit set in
   usr/lib. I don't think it's a big problem, but it makes them
   different from the others. libacl.so.1.1.0, libnettle.so.4.6,
   libhogweed.so.2.4, libattr.so.1.1.0, libesg.so,
   libicudata.so.48.1.1, libbind9.so.50.0.9, libisccc.so.50.0.3,
   libisccfg.so.50.0.6, libisc.so.57.1.0, liblwres.so.50.0.6,
   libmatroska.so.5, libucsi.so.libdns.so.110.1.2,
   lib_mp3_parser_arm11_elinux.so.3.1, lib_mp3_parser_arm9_elinux.so.1,
   libdvbapi.so, libdvbcfg.so, libdvben50221.so, libdvbsec.so,
   libproxychains4.so, nm-n.libdirect-1.6.so.0,
   nm-n.libdirectfb-1.6.so.0, nm-n.libfusion-1.6.so.0.

 * The gpsd-3.9 installs a libQgpsmm.prl file that isn't needed at
   execution time. It should be removed from the target.

 * The samba package installs a bunch of *.msg files (de.msg  en.msg
   fi.msg  fr.msg  it.msg  ja.msg  nl.msg  pl.msg  ru.msg  tr.msg).
   Note sure why those are in usr/lib directly.

 * There a bunch of *.sh scripts that look suspicious (tclConfig.sh
   xml2Conf.sh  xsltConf.sh).

 * The erlang installation in usr/lib/erlang/ looks strange. It has
   bin/, lib/, usr/ directories and a few others,
   usr/lib/erlang/usr/include contains some header files. Looks strange.

 * The usr/lib/valgrind contains some huge binaries (2.5 MB) that are
   statically linked. Does it make sense?

 * There is a usr/lib64 directory, which contains the libiscsi library.
   Seems like there's something wrong in the build procedure of this
   library, it should get installed in usr/lib.

 * For some reason, the "feh" package installs its stuff in usr/local
   rather than usr/. So, its documentation gets kept, its manpage gets
   kept, etc. The package should be fixed to install its stuff in usr/.

 * ltp-testsuite installs runalltests.sh, runltp and runltplite.sh
   directly in usr/. Not nice. And also a usr/runtest/ directory with a
   bunch of files in there.

 * Seems like the 'quota' package has some issues. It installs edquota,
   quotacheck and rpc.quotad in usr/sbin, but without execution
   permissions. It also installs a quotaoff -> quotaon symlink, but
   there's no quotaon file.

 * ltp-testsuite installs a usr/scenario_groups directory. And also
   usr/testcases and usr/testscripts.

 * The rt-tests package installs some source code in usr/src/backfire.
 
 * Some packages seem to confuse /var with /usr/var: cups, netatalk,
   squid, polkit-1, vtund, stunnel. Here's what I have in usr/var/ :

$ find usr/var/
usr/var/
usr/var/cache
usr/var/cache/squid
usr/var/cache/cups
usr/var/cache/cups/rss
usr/var/netatalk
usr/var/netatalk/CNID
usr/var/netatalk/CNID/README
usr/var/netatalk/README
usr/var/run
usr/var/run/squid
usr/var/run/cups
usr/var/run/cups/certs
usr/var/racoon
usr/var/logs
usr/var/log
usr/var/log/cups
usr/var/log/vtund
usr/var/lock
usr/var/lock/vtund
usr/var/lib
usr/var/lib/polkit-1
usr/var/lib/polkit-1/localauthority
usr/var/lib/polkit-1/localauthority/10-vendor.d
usr/var/lib/polkit-1/localauthority/30-site.d
usr/var/lib/polkit-1/localauthority/90-mandatory.d
usr/var/lib/polkit-1/localauthority/20-org.d
usr/var/lib/polkit-1/localauthority/50-local.d
usr/var/lib/stunnel
usr/var/spool
usr/var/spool/cups
usr/var/spool/cups/tmp

 * Again ltp-testsuite installs a file named usr/Version, and a binary
   called usr/ver_linux.

 * usr/share represents 428 MB, which includes 121 MB of locales (I
   didn't select the removal of locales in my configuration)

 * qt installs its demos and examples in usr/share/qt/{demos,examples},
   but it installs both the source code and binaries. It would probably
   make sense to get rid of the source code of the examples.

 * libatomic_ops installs some documentation in usr/share/libatomic_ops.

 * There is a usr/share/imx-mm/ directory, with a lot of example code,
   including the source code. Maybe not necessary.

 * Squid installs the translation of its error messages directly in
   usr/share/errors/<language>/, so it doesn't get purged as per the
   locale settings. And also usr/share/errors/ is very generic...

 * Sylpheed installs its manual and faq in usr/share/sylpheed.

 * gutenprint installs its documentation in usr/share/gutenprint/doc/

 * edje installs some examples with the source code in
   usr/share/edje/examples.

 * metacity installs a 'metacity.schemas' file at the root of the
   filesystem.

If people are interested in fixing some of those issues, reply to this
e-mail saying which issue you're going to have a look at.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Bizarre things on the allyespackageconfig build

[Yann E. MORIN]

Thomas, All,

On 2013-05-10 17:51 +0200, Thomas Petazzoni spake thusly:
> Following the allyespackageconfig, I did explore the generated
> output/target filesystem, and noticed a number of bizarre things that
> probably should be fixed:
[--SNIP--]
>  * There is a usr/arm-buildroot-linux-gnueabi directory, which contains
>    just a 'bin' subdirectory, which contains ar, as, ld, nm, etc.
> 
>    $ ls usr/arm-buildroot-linux-gnueabi/bin/
>    ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  strip
> 
>    That's a strange installation location for binutils.

These should be hard-links to their fully-qualified counterparts in
/usr/bin:
    arm-buildroot-linux-gnueabi-{ar,as,ld,ld,bfd,nm,objcopy,ranlib,strip}

That's typical of a binutils installation.

[--SNIP--]
>  * There a bunch of libraries that don't have the executable bit set in
>    usr/lib. I don't think it's a big problem, but it makes them
>    different from the others.

Shared libraries do not need to be executable, except the dynamic linker
ld.so which is both a progrm and a library.

Also, libc.so from {,e}glibc is also executable, but not he libc.so from
uClibc.

I think it is not a problem per-se, and I think shared libraries should
not be executable at all.

>  * Some packages seem to confuse /var with /usr/var: cups, netatalk,
>    squid, polkit-1, vtund, stunnel. Here's what I have in usr/var/ :
[--SNIP--]

Two options here:
  - ./configure --localstatedir=/var
    Some packages do set it in their .mk, eg. (=/var unless specified):
        avahi, sed, directfb, NM, lighttpd, dhcp (=/var/lib/dhcp),
        php, oprofile, xserver_xorg-server, samba, dbus, collectd,
        proftpd (=/var/run), sqlite, bind, dbus-glib, ndisc6, sql_net,
        sqlcipher, connman, pulseaudio
    Probably usefull to set it in the pkg-infra?

[--SNIP--]
>  * usr/share represents 428 MB, which includes 121 MB of locales (I
>    didn't select the removal of locales in my configuration)

Not a problem if locales where not /disabled/ in your config.

> If people are interested in fixing some of those issues, reply to this
> e-mail saying which issue you're going to have a look at.

I'll look at the /var issue.
Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Bizarre things on the allyespackageconfig build

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Fri, 10 May 2013 18:53:56 +0200, Yann E. MORIN wrote:

> >  * There is a usr/arm-buildroot-linux-gnueabi directory, which contains
> >    just a 'bin' subdirectory, which contains ar, as, ld, nm, etc.
> > 
> >    $ ls usr/arm-buildroot-linux-gnueabi/bin/
> >    ar  as  ld  ld.bfd  nm  objcopy  objdump  ranlib  strip
> > 
> >    That's a strange installation location for binutils.
> 
> These should be hard-links to their fully-qualified counterparts in
> /usr/bin:
>     arm-buildroot-linux-gnueabi-{ar,as,ld,ld,bfd,nm,objcopy,ranlib,strip}
> 
> That's typical of a binutils installation.

They are indeed hardlinks.

> [--SNIP--]
> >  * There a bunch of libraries that don't have the executable bit set in
> >    usr/lib. I don't think it's a big problem, but it makes them
> >    different from the others.
> 
> Shared libraries do not need to be executable, except the dynamic linker
> ld.so which is both a progrm and a library.
> 
> Also, libc.so from {,e}glibc is also executable, but not he libc.so from
> uClibc.
> 
> I think it is not a problem per-se, and I think shared libraries should
> not be executable at all.

I agree, it's not a problem per se, it's just that 99% of the other
packages install their shared libraries with executable permissions, so
not having them for a few libraries is a bit strange.

Also, to be noted that we keep the .so symbolic link, even though it's
generally unneeded at runtime. However, unfortunately, simply removing
*.so isn't going to work: some of the .so files are directly the shared
libraries.

Examples:

$ ls -l libdvb*
-rw-r--r-- 1 thomas thomas 20469 May  9 13:21 libdvbapi.so
-rw-r--r-- 1 thomas thomas 13415 May  9 13:21 libdvbcfg.so
-rw-r--r-- 1 thomas thomas 52375 May  9 13:21 libdvben50221.so
-rw-r--r-- 1 thomas thomas 25523 May  9 13:21 libdvbsec.so

> >  * Some packages seem to confuse /var with /usr/var: cups, netatalk,
> >    squid, polkit-1, vtund, stunnel. Here's what I have in usr/var/ :
> [--SNIP--]
> 
> Two options here:
>   - ./configure --localstatedir=/var
>     Some packages do set it in their .mk, eg. (=/var unless specified):
>         avahi, sed, directfb, NM, lighttpd, dhcp (=/var/lib/dhcp),
>         php, oprofile, xserver_xorg-server, samba, dbus, collectd,
>         proftpd (=/var/run), sqlite, bind, dbus-glib, ndisc6, sql_net,
>         sqlcipher, connman, pulseaudio
>     Probably usefull to set it in the pkg-infra?

Seems like yes.

> [--SNIP--]
> >  * usr/share represents 428 MB, which includes 121 MB of locales (I
> >    didn't select the removal of locales in my configuration)
> 
> Not a problem if locales where not /disabled/ in your config.

Sure, I was just giving a rough idea of the size of usr/share: it
represents almost half of the size of the filesystem. usr/share is 428
MB over the 1.1 GB of the filesystem. This line was mostly giving
numbers, not really raising any particular problem.

> > If people are interested in fixing some of those issues, reply to this
> > e-mail saying which issue you're going to have a look at.
> 
> I'll look at the /var issue.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Bizarre things on the allyespackageconfig build

[Yann E. MORIN]

Thomas, All,

On 2013-05-10 22:58 +0200, Thomas Petazzoni spake thusly:
> On Fri, 10 May 2013 18:53:56 +0200, Yann E. MORIN wrote:
> > [--SNIP--]
> > >  * There a bunch of libraries that don't have the executable bit set in
> > >    usr/lib. I don't think it's a big problem, but it makes them
> > >    different from the others.
> > 
> > Shared libraries do not need to be executable, except the dynamic linker
> > ld.so which is both a progrm and a library.
> > 
> > Also, libc.so from {,e}glibc is also executable, but not he libc.so from
> > uClibc.
> > 
> > I think it is not a problem per-se, and I think shared libraries should
> > not be executable at all.
> 
> I agree, it's not a problem per se, it's just that 99% of the other
> packages install their shared libraries with executable permissions, so
> not having them for a few libraries is a bit strange.

Yep, I like my filesystems to be tidy, too! :-)

> Also, to be noted that we keep the .so symbolic link, even though it's
> generally unneeded at runtime. However, unfortunately, simply removing
> *.so isn't going to work: some of the .so files are directly the shared
> libraries.
> 
> Examples:
> 
> $ ls -l libdvb*
> -rw-r--r-- 1 thomas thomas 20469 May  9 13:21 libdvbapi.so
> -rw-r--r-- 1 thomas thomas 13415 May  9 13:21 libdvbcfg.so
> -rw-r--r-- 1 thomas thomas 52375 May  9 13:21 libdvben50221.so
> -rw-r--r-- 1 thomas thomas 25523 May  9 13:21 libdvbsec.so

What we could do is scan the rootfs for shared libs, remove the
symlinks, and rename the libraries to their SONAME.

Then, until we get rid of "devel stuff on target", we can recreate the
simple .so symlinks (if it's not the SONAME).

Also, keep in mind that symlinks each use an inode, which can become a
bit cumbersome on size-constrained file systems. (hardlinks do not use
an inode, however). So, getting rid of the useless symlinks is a net
win overall.

> > >  * Some packages seem to confuse /var with /usr/var: cups, netatalk,
> > >    squid, polkit-1, vtund, stunnel. Here's what I have in usr/var/ :
> > [--SNIP--]
> > 
> > Two options here:
> >   - ./configure --localstatedir=/var
> >     Some packages do set it in their .mk, eg. (=/var unless specified):
> >         avahi, sed, directfb, NM, lighttpd, dhcp (=/var/lib/dhcp),
> >         php, oprofile, xserver_xorg-server, samba, dbus, collectd,
> >         proftpd (=/var/run), sqlite, bind, dbus-glib, ndisc6, sql_net,
> >         sqlcipher, connman, pulseaudio
> >     Probably usefull to set it in the pkg-infra?
> 
> Seems like yes.

I've done a preliminary build with that and no /usr/var symlink, and it
is not satisfactory to me: for example, cups will install some stuff in
/tmp :
    before                          after
    ----------------------------------------------------------
    /usr/var/run/cups/certs/        /tmp/cups/certs/
    /usr/var/cache/cups/rss/        /tmp/cups/rss/
    /usr/var/spool/cups/tmp/        /tmp/cups/tmp/

So, because /var/run, /var/spool. and /var/cache are symlinks to /tmp,
all gets install into /tmp/cups.

I'm not sure this is good, as /tmp is not guaranteed to survive a
shutdown, especially since /tmp is a tmpfs in the default skeleton.
Which causes even further grievance since the mountpoint will hide
the previous content of /tmp anyway.

I'll see how to "fix" that.

Other than that, all the packages you mentionned installing things in
/usr/var did install in /var, and /usr/var was not created. Which is
otherwise good news.

Anyway, that still requires a bit more investigations before I can
submit that.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Bizarre things on the allyespackageconfig build

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sat, 11 May 2013 00:27:39 +0200, Yann E. MORIN wrote:

> > I agree, it's not a problem per se, it's just that 99% of the other
> > packages install their shared libraries with executable permissions, so
> > not having them for a few libraries is a bit strange.
> 
> Yep, I like my filesystems to be tidy, too! :-)

Me too. I also noticed some variations on the permissions of
executables. Most of them have the write permissions, but some do not.


> > Also, to be noted that we keep the .so symbolic link, even though it's
> > generally unneeded at runtime. However, unfortunately, simply removing
> > *.so isn't going to work: some of the .so files are directly the shared
> > libraries.
> > 
> > Examples:
> > 
> > $ ls -l libdvb*
> > -rw-r--r-- 1 thomas thomas 20469 May  9 13:21 libdvbapi.so
> > -rw-r--r-- 1 thomas thomas 13415 May  9 13:21 libdvbcfg.so
> > -rw-r--r-- 1 thomas thomas 52375 May  9 13:21 libdvben50221.so
> > -rw-r--r-- 1 thomas thomas 25523 May  9 13:21 libdvbsec.so
> 
> What we could do is scan the rootfs for shared libs, remove the
> symlinks, and rename the libraries to their SONAME.
> 
> Then, until we get rid of "devel stuff on target", we can recreate the
> simple .so symlinks (if it's not the SONAME).
> 
> Also, keep in mind that symlinks each use an inode, which can become a
> bit cumbersome on size-constrained file systems. (hardlinks do not use
> an inode, however). So, getting rid of the useless symlinks is a net
> win overall.

Interesting, those libdvb*.so libraries don't have a SONAME:

$ readelf -d libdvb*.so | grep SONAME
$

Seems like they might be dlopen()ed plugins and not directly shared
libraries per se.

However, some of those non-executables libraries do have a SONAME:

target/usr/lib$ ls -l libproxychains4.so 
-rw-r--r-- 1 thomas thomas 85619 May  9 17:18 libproxychains4.so
target/usr/lib$ readelf -d libproxychains4.so | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libproxychains4.so]

I'm not sure I like the renaming of libraries to their SONAME, but it's
really a matter of perception. Technically speaking, I agree that it
works.

> I've done a preliminary build with that and no /usr/var symlink, and it
> is not satisfactory to me: for example, cups will install some stuff in
> /tmp :
>     before                          after
>     ----------------------------------------------------------
>     /usr/var/run/cups/certs/        /tmp/cups/certs/
>     /usr/var/cache/cups/rss/        /tmp/cups/rss/
>     /usr/var/spool/cups/tmp/        /tmp/cups/tmp/
> 
> So, because /var/run, /var/spool. and /var/cache are symlinks to /tmp,
> all gets install into /tmp/cups.
> 
> I'm not sure this is good, as /tmp is not guaranteed to survive a
> shutdown, especially since /tmp is a tmpfs in the default skeleton.
> Which causes even further grievance since the mountpoint will hide
> the previous content of /tmp anyway.
> 
> I'll see how to "fix" that.
> 
> Other than that, all the packages you mentionned installing things in
> /usr/var did install in /var, and /usr/var was not created. Which is
> otherwise good news.
> 
> Anyway, that still requires a bit more investigations before I can
> submit that.

Ok. Beware that having /var/run, /var/spool and /var/cache point
to /tmp is a feature that allows the root filesystem to be mounted
read-only, and still have the services working. That's something we
should try to keep working, I believe.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Bizarre things on the allyespackageconfig build

[Yann E. MORIN]

Thomas, All,

On 2013-05-11 12:31 +0200, Thomas Petazzoni spake thusly:
> On Sat, 11 May 2013 00:27:39 +0200, Yann E. MORIN wrote:
> > Yep, I like my filesystems to be tidy, too! :-)
> Me too. I also noticed some variations on the permissions of
> executables. Most of them have the write permissions, but some do not.

I'm not sure whether we should "clean up" this situation. Although I
agree this is not "clean", it's the same problem as with +x/-x shared
libs.

At the last DevDay, we discussed about having target generated from
staging just before the filesystem images are created. When we come to
implement this, then maybe we can clean that situation a bit. And at the
same time, also take care of the shared lib SONAME "issue"...

> Interesting, those libdvb*.so libraries don't have a SONAME:
> 
> $ readelf -d libdvb*.so | grep SONAME
> $
> 
> Seems like they might be dlopen()ed plugins and not directly shared
> libraries per se.

Yep, most probably dlopn()ed plugins.

> However, some of those non-executables libraries do have a SONAME:
> 
> target/usr/lib$ ls -l libproxychains4.so 
> -rw-r--r-- 1 thomas thomas 85619 May  9 17:18 libproxychains4.so
> target/usr/lib$ readelf -d libproxychains4.so | grep SONAME
>  0x0000000e (SONAME)                     Library soname: [libproxychains4.so]
> 
> I'm not sure I like the renaming of libraries to their SONAME, but it's
> really a matter of perception. Technically speaking, I agree that it
> works.

I see at least one reason to rename to the SONAME: get rid of the
symlinks to reduce the number of inodes required on the filesystem.

Granted, we do not gain much, but it is still interesting on a small FS.

> > I've done a preliminary build with that and no /usr/var symlink, and it
[--SNIP--]
> Ok. Beware that having /var/run, /var/spool and /var/cache point
> to /tmp is a feature that allows the root filesystem to be mounted
> read-only, and still have the services working. That's something we
> should try to keep working, I believe.

Yes, I know. But currently, those packages are already broken, since
they point to /usr/var which might be read-only.

So I wonder what the best situation would be to fully solve the issue. I
can see at least two options:
  - package provides an init script (or systemd unit) that creates the
    required dirs/files at startup;
  - infra creates a tarball of everyting in /tmp and install a startup
    script that extracts that tarball at startup.

Needless to say that I prefer the first solution, although it will
require a bit more work (eg. currently, cups bundles and installs its
startup script (which BTW is largely more complex than it needs to be),
so we'd have to replace that startup script with our own, which is not
really trivial).

OTOH, the second solution is relatively easy to do, and is systematic,
although it may entice developpers to lazyness.

Regards,
Yann E. MORIN.

PS. I again have some mail delivery issues this WE, and although it seems
    to settle down, I'm not sure I'm receiving mails on-time (this one
    arrived about an hour ago... :-( ). Looks like time for me to roll
    out my own server... :-(
YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Bizarre things on the allyespackageconfig build

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 Yann> Yes, I know. But currently, those packages are already broken, since
 Yann> they point to /usr/var which might be read-only.

 Yann> So I wonder what the best situation would be to fully solve the issue. I
 Yann> can see at least two options:
 Yann>   - package provides an init script (or systemd unit) that creates the
 Yann>     required dirs/files at startup;
 Yann>   - infra creates a tarball of everyting in /tmp and install a startup
 Yann>     script that extracts that tarball at startup.

 Yann> Needless to say that I prefer the first solution, although it
 Yann> will require a bit more work (eg. currently, cups bundles and
 Yann> installs its startup script (which BTW is largely more complex
 Yann> than it needs to be), so we'd have to replace that startup script
 Yann> with our own, which is not really trivial).

Yes, I believe we do something similar for some of the packages in the
gtk stack (gdk-pixbuf or pango or so).

-- 
Bye, Peter Korsgaard

[Buildroot] Bizarre things on the allyespackageconfig build

[Arnout Vandecappelle]

On 10/05/13 17:51, Thomas Petazzoni wrote:
>   * qt installs its demos and examples in usr/share/qt/{demos,examples},
>     but it installs both the source code and binaries. It would probably
>     make sense to get rid of the source code of the examples.

  Since the demos/examples are typically not installed in a production 
system but just during development or to showcase things, I don't think 
it is worth the effort to hack the makefiles or to do explicit 
post-processing to remove the source code. If the user wants it, it can 
still be done in a post-build script.

  Same goes for qt5, edje, etc.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F