No subject

pull whichever libnl-xxx package I need.

Thanks
Alex

--047d7b5d5c22b23b410520555535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Sep 17, 2015 at 5:13 PM, Alexandru Ardelean <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ardeleanalex at gmail.com" target=3D"_blank">ardeleanalex at gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div><div class=3D"h5"><br><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Thu, Sep 17, 2015 at 4:50 PM, Felix Fietka=
u <span dir=3D"ltr"><<a href=3D"mailto:nbd at openwrt.org" target=3D"_blank=
">nbd at openwrt.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><span>On 2015-09-17 15:05, Alexandru Ardelean wrote:<br>
> From: Alexandru Ardelean <<a href=3D"mailto:aa at ocedo.com" target=3D=
"_blank">aa at ocedo.com</a>><br>
><br>
> The idea is that we may only need the libnl core,<br>
> or libnl-route or libnl-nf libs, but maybe not all of them.<br>
><br>
> This way we can select which ones we need without bloating the<br>
> firmware image too much.<br>
><br>
> Signed-off-by: Alexandru Ardelean <<a href=3D"mailto:ardeleanalex at g=
mail.com" target=3D"_blank">ardeleanalex at gmail.com</a>><br>
</span>Maybe it would be better to have libnl as a metapackage selecting<br=
>
libnl-core + the other ones. The way you split the package, you might be<br=
>
breaking some packages that depend on it.<br>
<br>
Or did you review all of the packages to ensure that they only need the<br>
core?<br>
<span><font color=3D"#888888"><br>
- Felix<br>
</font></span></blockquote></div><br></div></div></div><div class=3D"gmail_=
extra">Good point.<br></div>I only took a look at base packages.<br><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Looking through th=
e packages feed, there's keepalived , ibrcommon, kismet, bmon and aircr=
ack-ng that depend on libnl.<br></div><div class=3D"gmail_extra">Other feed=
s don't have libnl deps.<br></div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">I'll check if libnl is sufficient and if not=
, implement your suggestion.</div><div class=3D"gmail_extra"><br></div><div=
 class=3D"gmail_extra">Thanks<br></div><div class=3D"gmail_extra"><br></div=
></div>
</blockquote></div><br><div><div><div><div><div><div>Seems I'll have to=
 re-spin this patch.<br></div><div>There are a few things that need updatin=
g on it. They came up once I did a full clean + rebuild.<br></div><div>I fo=
rgot about the staging dir stuff that piles up and causes false-successes.<=
br></div><div><br></div>So, <br></div>- bmon requires libnl-route<br></div>=
- aircrack-ng requires libnl-genl<br></div>- kismet i am not sure 100% ; ma=
ybe libnl-genl ; I did not want to investigate much deeper<br></div>- ibrco=
mmon requires libnl-genl and libnl-route<br></div>- keepalived requires lib=
nl-genl<br><div><br></div><div>Hopefully I got most of this right.<br></div=
><div><br></div>Now, here's the bloat for libnl:<br>- 86856 Sep 22 14:0=
0 libnl-3.so.200.16.1<br>- 244304 Sep 22 14:00 libnl-route-3.so.200.16.1<br=
>- 16096 Sep 22 14:00 libnl-genl-3.so.200.16.1<br></div><div class=3D"gmail=
_extra">- Seems libnl-nf is not needed. That's around 80k.<br></div><di=
v class=3D"gmail_extra">- libnl-tiny is 30k<br></div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">Maybe aircrack-ng and keepalived =
could also work with [just] libnl-tiny, but that's another discussion.<=
br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I =
need libnl-route for an upcoming new lldpd version, which will require libn=
l-route.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">The main reason I started this split, is because I need libnl-route,=
 and I am trying to minimise the bloat wherever I can.<br></div><div class=
=3D"gmail_extra">I'll also see about pulling libnl-tiny out [in my case=
], since I'll be stuck with needing libnl anyway.<br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Anyway, moving forwar=
d with the split: <br>1) Do I rename the libnl package to libnl-core and ma=
ke libnl a metapackage that pulls in everything ? or<br></div><div class=3D=
"gmail_extra">2) Do I leave this structure as is (with the fixes/updates I&=
#39;ll add later) and update those packages to pull only the libfiles that =
are needed ? <br></div><div class=3D"gmail_extra">For 2), I'd of-course=
 need the approval/blessing of the package maintainers above.<br></div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">From my point o=
f view any of these 2 approaches is fine, because I can just pull whichever=
 libnl-xxx package I need.<br></div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">Thanks<br></div><div class=3D"gmail_extra">Alex<br=
></div><div class=3D"gmail_extra"><br></div></div>

--047d7b5d5c22b23b410520555535--

--===============4020578527749874754==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

--===============4020578527749874754==--