[Ns-developers] Fedora 17 packaging status

Tom Henderson tomh at tomh.org
Sun Mar 11 22:42:09 PDT 2012


Some questions/comments inline below:

On 03/08/2012 05:05 PM, Vedran Miletić wrote:
> Hi guys,
> I will submit Fedora 17 RPM (of ns-3-dev versioned something like
> 3.14-0.2.hg7755) package for review this week or early next week.

Since we do not yet have ns-3.14 code, is the intent that we will submit 
a real ns-3.14 (versioned 3.14-1) version before some Fedora freeze date 
(if so, what date?), or would we just do a post-FC 17 update when 
ns-3.14 ships?  How would a bugfix ns-3.14.1 release be versioned?

Is the expectation that we maintain ns-3.14 throughout the Fedora 17 
maintenance cycle (which appears to be 13 months)?   What are the 
expectations that Fedora has (if any) in this regard?

> Let's do a checklist of current status to see if I missed something:
> -- it's named ns, not ns-3 or ns3, as Qt4 package is named qt in
> Fedora, Perl 5 package is named perl etc.

Note that YunQiang Su has been maintaining Debian ns-2 packages under 
the name 'ns2'.  If/when someone has packaged both ns-2 and ns-3 in a 
future Fedora distribution, how would they be named?

> -- it packages both debug and optimized libraries and binaries in a
> versioned way

which binaries?  I wasn't sure how you decided to deal with examples and 
tests.  From your draft spec file, I don't see any.  Note that I'm not 
sure the binaries are that useful for this use case (outside of perhaps 
the tutorial binaries).

In what circumstances do you envision that future users would not be 
installing the devel version?  (i.e. are people just going to be 
typically installing 'ns-devel')?

> -- headers are versioned as well, pkg-config files handle that from
> user's perspective so it works nicely
> -- it packages Python bindings only for optimized libs (as far as I
> see it's not possible to package both)
> -- it includes all modules except visualizer (Fedora lacks some
> dependencies), openflow and click

Could the pyviz omission be remedied (such as by including the missing 
package's code)?  Which dependencies are missing?

> -- nsc is not packaged (I'm not sure it should be, as it crashes with
> SELinux on unless allow_execstack is set)
> -- documentation is not packaged (it probably should be)

are there guidelines for what should be added in this regard?  Would we 
just include the html that we now generate?  (doxygen and Sphinx files)?

> -- specfile http://www.inf.uniri.hr/~vmiletic/ns-3/ns.spec is still
> rough on the edges but it will be cleaned up for final 3.14 (note that
> it currently also requires a custom assembled tarball with GCC 4.7
> patches and some other manual changes)
> Suggestions? Something that I forgot?

Will we need too manage this on git://pkgs.fedoraproject.org in the future?

Could we perhaps testdrive the rpms that you are now producing before 
submitting upstream?

Where would the sample code reside for users to integrate to their build 
system (e.g. configure.ac:
Is this new documentation that needs to be written now?

Regarding tests, it seems that perhaps we would want to be able to build 
a version of the test-runner binary that linked these installed 
libraries and be able to run them in different modes from a separate 
buildslave.  Does that seem about right?

- Tom

More information about the Ns-developers mailing list