[Ns-developers] Fedora 17 packaging status

Vedran Miletić rivanvx at gmail.com
Mon Mar 12 09:02:38 PDT 2012


12. ožujka 2012. 06:42 korisnik Tom Henderson <tomh at tomh.org> napisao je:
> Vedran,
>
> Some questions/comments inline below:

OK.

> 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?

Yes. Final F17 release will have something like

ns-3.14-1.fc17

in case of packaging bugs or minor patches added on top of it

ns-3.14-2.fc17

and then 3.14.1 will have

ns-3.14.1-1.fc17

and so on. -0.something is reserved for alphas and betas.

> 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?

None. I can submit 3.15 as an update, as I will do. Users wanting both
will still be able to get both installed (with Python bindings for one
or the other), but this will not be the default behaviour.

Debian and Ubuntu, however, do expect either upstream or downstream
developers to maintain the version one has packaged.

>> 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?

ns-3 will be ns, ns-2 will be ns2. In Fedora Qt4 is qt, and Qt3 is
qt3, i.e. the "active" version is one that doesn't get a version
number. But it's not a strict rule, we can also name it ns3. I will
see what package reviewer suggests in this regard, but currently
Fedora has no package named ns.

>> -- 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).

I'm not sure we want to package those, i.e. they are more useful as
source code than binary.

User that wants the source code can install SRPM.

> 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')?

Yes. Fedora requires separation. Same is done for boost. Only case
where users wouldn't be installing devel is in case we once decide to
package NEPI/NEF/NETNS and user install ns-3 as a dependency.

>> -- 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)

Are people on the list aware that Python bindings are not versioned?
It's mostly because I don't see a sane way to do that.

>> -- 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?

Sure. PyGraphviz is the only package, I believe. I had a working
specfile at some point but it was too dirty to pass review. Will do
it.

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

Any thoughts on packaging nsc?

>> -- 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)?

Yes, and install them in appropriate location. Some waf changes could
be useful here.

>> -- 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?

I believe so.

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

Absolutely.

> Where would the sample code reside for users to integrate to their build
> system (e.g. configure.ac:
> PKG_CHECK_MODULES([X], [x])?
> Is this new documentation that needs to be written now?

Yes. I could contribute the part regarding qmake which is what we use here.

> 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?

Yes. However, I will point out again that (at least on F17) some tests
fail due to SELinux execstack protection, so we need to either disable
it or expect tests to fail.

Vedran

> - Tom




More information about the Ns-developers mailing list