On 3/11/19 4:18 AM, Pierre Labastie via blfs-dev wrote:
On 11/03/2019 09:03, Pierre Labastie via blfs-dev wrote:
On 11/03/2019 08:34, Douglas R. Reno wrote:
On Mon, Mar 11, 2019, 2:23 AM Pierre Labastie via blfs-dev
<[email protected]
<mailto:[email protected]>> wrote:
On 10/03/2019 22:22, Bruce Dubbs via blfs-dev wrote:
> I've added the page:
>
> http://www.linuxfromscratch.org/blfs/view/svn/general/lua52.html
>
> to add in the older lua-5.2 package in support of wireshark as well as
> potentially other programs.
>
> I request that others build this package and provide feedback to see if I
> missed anything. It's a very short build -- less than 0.1 SBU, but
getting
> two versions of the same package installed properly is a bit tricky.
>
What's the interest of having lua (whatever version) in wireshark? As far
as I
know, lua bindings are not needed for proper operation of wireshark. They
can
add scripting support to Wireshark, for making complicated things, but it
could be made optional in the book...
Also, going back to an old version of a package, because a patch does not
apply anymore to use a newer version might not be the best way to get the
"latest and greatest"...
Or maybe this is the other way around: we should check what needs lua in
the
book, and maybe remove the latest version... Or remove it completely, if
it is
optional.
Pierre
--
It has to do with the modules that packages such as Samba installed. Without
Lua support, the module that Samba installs to allow CIFS traffic to be
understood can't be used.
Good to know, but maybe samba could use lua 5.2? Or maybe wireshark's patch
could be updated for new wireshark version? Or just wireshark could be built
without lua? In any case, it would be much better than having two versions of
the same package in the book...
Wrong answer, sorry: samba can use (optionally) wireshark's lua bindings... I
thought samba was directly dependent on lua.
We just have had an argument about maintenance ease recently, whether having
two different packages on the same page is more or less maintenance burden.
One thing I'm sure about is that having two versions of the same package in
the book is _much more_ a maintenance burden...
Thinking more about it, I'd say that the least maintenance heavy path is to
remove lua support for wireshark...
I don't think that anymore now, if wireshark can be used to analyse CIFS
traffic (do I understand correctly now?): it's the aim of wireshark to analyse
all sorts of traffic. But I still think it will be a maintenance burden...
So there are 2 options left:
- adapt the lua-5.3 patch for new wireshark version.
- have only lua-5.2 in the book
I've looked for packages dependent on lua. According to the (SysV) book:
- highlight requires it (can it be lua-5.2?)
- hexchat and vlc recommend it (same question)
- it is optional for nano, ptlib, gegl, graphviz, wireshark, apache, dovecot,
gtk-engines, keybinder.
- libpeas is said to depend optionally on luajit. It looks like luajit is
somehow independent on lua (same language, but completely different
implementation).
- totem-pl-parser is said to depend optionally on lua-socket--git. Don't know
what it is.
When I updated wireshark, I was surprised that they still don't support
lus-5.3. Upon investigation, they decided that 5.3 broke too many
scripts that users have.
I found this note in tools/macos-setup.sh
# Use 5.2.4, not 5.3, for now; lua_bitop.c hasn't been ported to 5.3
# yet, and we need to check for compatibility issues (we'd want Lua
# scripts to work with 5.1, 5.2, and 5.3, as long as they only use Lua
# features present in all three versions)
I also checked Arch and they also have lua52 in their system.
I don't think lus52 will change much, if at all, so the maintenance
burden will be low.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
