#255 Bundling exception request for nmap
Closed: Fixed None Opened 11 years ago by mhlavink.

Hi,

nmap package post 6.01 version requires newer version of lua library than the one available in Fedora.

lua >= 5.2 is required

Lua 5.2 was released on 16 Dec 2011 [http://www.lua.org/versions.html#5.2]
yet Fedora still uses version 5.1.4 (latest 5.1.x release is Lua 5.1.5, released on 17 Feb 2012, a year ago).

I thought about filling a bugzilla request to update lua in Fedora, but I found there already was one:
https://bugzilla.redhat.com/show_bug.cgi?id=815263

With no action, half a year later maintainer decided that it will probably be Feature for Fedora release, but there was still no action. Before Feature submission deadline I reminded that the deadline is close, but no action and no response.

As Lua maintainer does not seem to focus on Fedora's First goal and it will be another half a year (minimum) before Fedora gets updated Lua package, I'd like to use newer Lua to build up-to-date nmap releases.

Nmap upstream tarball already has a few required libraries including Lua, but I remove them from sources during %prep phase.

Answers to standard questions about bundling a library:
- no difference from upstream Lua 5.2 release
- N.A. - it's not a fork
- other packages could profit from newer version, there are useful changes, it's new upstream release with new features and bug fixes
- nmap upstream keeps the library updated
- nmap's upstream attitude towards bundling is "bundled library is not necessary, but we provide it, so you are able to build nmap in case you don't have it"
- security POV - this is newer version with more fixes than old 5.1.4 in Fedora
- comments from Fedora's maintainer - asked to update lua several times, no action during last year, he will probably update lua but who know when it will happen
- there is a plan to unbundle the library once the lua in Fedora meets build requirement

So, I'd like to ask for exception to use upstream provided Lua library until Lua in Fedora is updated to meet the requirements.

Thanks


Just like forking any other language, I would be extremely hesitant to promote bundling of lua.

The best answer here would be to pull together the people needed to port to the new lua and then work with the maintainer to identify which packages need porting and proceed with porting. I agree that this really should have a Feature to coordinate and publicize the change... That probably makes this too late for F19... F20 would be a good target and coordination/specing of the problem space could begin now. Committing patches could start as soon as F19 branches from rawhide. (You could ask for an exception to make this an F19 feature but you'd need to have a very good idea of the scope of changes needed in order to get fesco to look at it... I somewhat doubt that they'll approve a late feature for F19 even then as F19 is on a compressed schedule to make up for F20 but you can try).

If you absolutely must get this into F19, then the FPC doesn't stand in the way of parallel installable language stacks. ie: a parallel installable lua5.2-5.2 or lua5.1-5.1 package. You'd need to coordinate with the lua maintainer to see whether he would prefer a forward compat or backwards compat package (I believe that fesco has a policy allowing the primary package's maintainer to veto a parallel language stack as well so coordination with the primary lua packager is essential). I would say, however, that I don't like parallel installable language stacks in Fedora. They create a large extra burden of work that would probably be better spent in porting rather than in packaging parallel versions of software.

I thought the exception in a way to use lua that nmap upstream provides in it's tarball (latest release) and link it statically. This should not affect any other package except nmap itself. I'd like to do that not only in F19, but in F18 too. Old netcat in F18+ was orphaned and nmap-ncat became replacement of old nc in Fedora 18+. We (me and Tomas Hozza) worked with nmap upstream to make it more compatible with old netcat, so there is minimum changes in behaviour, but right now we can't use those releases in Fedora.

Temporary exception for nmap to bundle newer version of lua in f19 only Current vote: (+1:3, 0:0, -1:2) voting to continue in ticket

... and I see now that it would have been better for me to propose that we allow a temporary exception for bundling a newer version of lua in f18 and f19 rather than f19 only. I don't believe that would change any votes but -- if tibbs and rdieter would like to revote; new proposal:

Temporary exception for nmap to bundle newer version of lua for f18 and f19 only.

  • +1 (1) toshio (rdieter and tibbs can confirm they still support this)
  • -1 (2) racor and geppetto

Need votes from: spot, rathann, smootherfr0gz, limburgher, (tibbs and rdieter to confirm their +1's)

The FPC members who voted against this were firmly of the opinion that a parallel installable lua stack would be more desirable than bundling.

For F20 and beyond, everyone was in agreement that lua either needs to be upgraded or we need a parallel installable stack. If a parallel installable stack, it is preferable to have lua move to the new version and have a lua5.1 package that is for backwards compat.

We also noted that to move forward to new lua (whether or not this bundling exception is approved) the nmap maintainers are strongly urged to get the process of porting packages to the new lua started. Waiting and assuming that someone else is going to do the work is just asking for a problem when F20 rolls around.

confirm, +1 to pretty much any temporary bundling.

I'd really rather see Lua updated in f19, especially since Panu gave the OK from the RPM perspective. Creating lua5.1 is good, but it won't get lua updated, and given the timeframes sometimes involved in reviews, testing, etc, it might be moot, depending on how has the lua maintainer moves on the update. We're past feature submission, but there's nothing in stone saying this must be a feature.

That said, I'm +-0 on bundling.

+1 to the updated proposal. Obviously I would also rather see lua updated in F19, but at this point we have no idea what the lua maintainers are willing to do and there's the question of everything that would break with the update.

Replying to [comment:3 toshio]:

the nmap maintainers

It's just me. I asked Tomas Hozza to help me polish nmap-ncat (A.K.A. new nc) in a timely manner, but he is no (co-)maintainer of nmap.

the nmap maintainers are strongly urged to get the process of porting packages to the new lua started. Waiting and assuming that someone else is going to do the work is just asking for a problem when F20 rolls around.

I thought it works the same way as mass rebuilds or any other library updates. Do an update soon after branching and let package maintainers fix their packages. If I understand your proposal that I should fix all lua 5.2 incompatible packages or prepare extra compat package (which would still require lua's maintainer cooperation), then it'd require more resources than I can spend.

You know, reading Toshio's response in comment 3 again, I think something out wrong. The sentence "the nmap maintainers are strongly urged to get the process of porting packages to the new lua started" can't be what we actually discussed. I think "nmap" should be "lua" there; obviously it's not sensible for the nmap maintainers to get the rest of the distro migrated to a new lua.

Well, nmap is somewhat what I meant. We need a plan for lua in F20 that doesn't include bundling. There are several possibilities:

  • nmap is ported to run on older lua
  • main lua package updated and everything is ported to the new lua or retired from F20
  • parallel installable lua packages are created and packages are updated to build against whichever version of lua they require

Who does this work is flexible. As the nmap maintainer facing the deadline of not being able to bundle lua at F20, there's a need to communicate with the present lua maintainers and come up with a plan whether or not they are willing to update the main lua package in that timeframe. That could mean porting the dependent packages to help convince them that it's a good idea. It could also mean packaging and getting the parallel installable lua5.2 package reviewed for F20. It could mean filing a nonresponsive maintainer ticket against the lua packager.

The wording is meant to express to the nmap maintainer that this is a grace period in which they have to figure out how to choose from several potentially bad alternatives. They can't expect to get an extension of the exception for F20. A repeat of pinging the bug near the F20 Feature Deadline and getting no response from the official maintainer will put the nmap maintainer in a difficult position. It's much better if they try to do something about the situation now rather than then.

+1 from me for temporary bundling exception.

We're at
+1: 4
0: 1
-1: 2

votes still needed from Rathann and spot. I'll also ping the lua ticket to see if I get any response from the maintainers about what their plans are.

+1 for temporary bundling exception

That takes us to (+1: 5, 0: 1, -1: 2). Temporary bundling exception passes. I've updated the list on No_bundled_libraries.

Please use a virtual Provides of:

Provides: bundled(lua) = 5.2

In your package.

Replying to [comment:13 toshio]:

Temporary bundling exception passes.

Thank you

Please use a virtual Provides of:
Provides: bundled(lua) = 5.2

Done

Metadata Update from @rdieter:
- Issue assigned to tibbs

7 years ago

Login to comment on this ticket.

Metadata