From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] e2fsprogs.inc - break shared libs into separate packages
Date: Tue, 04 Jan 2011 09:18:33 +0100 [thread overview]
Message-ID: <iful4p$9us$1@dough.gmane.org> (raw)
In-Reply-To: <4D22A477.5010205@mwester.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04-01-11 05:39, Mike Westerhof wrote:
> On 1/3/2011 1:49 AM, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03-01-11 02:03, Mike Westerhof wrote:
>>> On 1/2/2011 11:41 AM, Koen Kooi wrote:
>>> On 02-01-11 16:15, Mike Westerhof wrote:
>>>>>> Break the two shared libraries (libe2p and libext2fs) out of the general e2fsprogs
>>>>>> package and into their own packages. This avoids pulling in unwanted executables
>>>>>> when a distro only desires the basic tools (such as e2fsck and/or mke2fs).
>>>>>>
>>>>>> Signed-off-by: Mike Westerhof <mike@mwester.net>
>>>
>>> Recipes with e2fsprogs in DEPENDS will need a PR bump as well, since
>>> they might link to these libs as well. This will result in missing
>>> libraries when using package feeds.
>>>
>>>> Ok, I can do that. But I'm not sure I understand why this is the case.
>>>> OE detects the dependencies on the shared libs, and automagically adds
>>>> the necessary dependencies to the opkg control file. Hence, if opkg on
>>>> a device updates "e2fsprogs", it will see that the new version of
>>>> "e2fsprogs" depends on the two new libraries, and it should pull those
>>>> in from the feeds as well.
>>>
>>>> Perhaps a use-case that will fail will help me understand, and
>>>> consequently, help me put together a more-correct patch.
>>
>> Say you have built gparted which (r)depends on e2fsprogs and links to
>> libe2p. After this patch the "old" gparted in the feeds will only pull
>> in e2fsprogs and not libe2p.
>> If the e2fsprogs package rdepends on libe2p and friends this isn't a
>> problem, but if it doesn't you'll get spurious libs. This has happened a
>> number of times in the past and I'd like to avoid it happening in the
>> future :)
>
> Got it. So here's the pertinent line from the control file in the
> e2fsck ipk:
>
> "Depends: util-linux-ng, e2fsprogs-badblocks, libext2fs2, libcom-err2,
> libe2p2, libuuid1, libc6, libgcc1, libss2, libblkid1"
>
> Both new library packages (libext2fs2 and libe2p2) are present and will
> be pulled in by opkg, so no other packages will require PR bumps.
Awesome! Thanks for checking.
Acked-by: Koen Kooi <koen@openembedded.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFNItfZMkyGM64RGpERAvCLAKC9BjKNaH7OCwb+zCLTa383UpGJ7ACgpJrR
Nm9ZRWgWzxEdXMInxccB3yE=
=TyUM
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2011-01-04 8:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4D20968B.4030004@mwester.net>
2011-01-02 17:41 ` [PATCH] e2fsprogs.inc - break shared libs into separate packages Koen Kooi
2011-01-03 1:03 ` Mike Westerhof
2011-01-03 7:49 ` Koen Kooi
2011-01-04 4:39 ` Mike Westerhof
2011-01-04 8:18 ` Koen Kooi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='iful4p$9us$1@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.