[Ns-developers] Fedora 17 packaging status
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
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?
More information about the Ns-developers