[xen-tools-discuss] [xen-tools-dev] Fedora RPM for xen-tools

[Dario Faggioli]

On lun, 2013-04-01 at 12:49 +0200, Axel Beckert wrote:
> Hi Dario,
> 
Hi!

> Were you at FOSDEM, at the Xen booth? I visited the booth once but
> missed to meet at least Ian Campbell.
> 
I was, and I stayed at the Xen booth for quite some time... I'm the
second from right in the group picture (the one with the SuSE chameleon)
here http://blog.xen.org/index.php/2013/02/05/fosdem13-personal-impressions/

> > This mail to let you know that I'm starting working on packaging
> > xen-tools for Fedora. Long term, I plan to follow all the step
> > required to have the package properly accepted in the distro's
> > official repositories... For now, I just prepared an RPM for
> > everyone to (test and) use. :-)
> 
> 3x Yay!
> 
:-)

> I've got an idea what you mean. I noticed recently, that the
> per-distribution hooks are installed into /usr/lib/ instead of
> /usr/share/ where they should belong, and was surprised that Debian's
> lintian checks didn't go off about that, because Debian cares about
> the difference between /usr/share and /usr/lib, too.
>
Well, this is the biggest complaint of rpmlint, i.e., something I really
need to take care of before even trying to submit the package officially
to Fedora. So, are you saying that you're going to move the hooks
to /usr/share ?

> Do you have your packaging in some VCS repo?
> 
Not yet, but I plan to. Will keep the lists posted.

> You seem to not throw away the .spec file in misc/, so I suspect, it
> doesn't hurt at that place? Or do you think I should I remove (the
> likely not enough maintained) .spec file and point instead to your
> package?
> 
I don't think it hurts to have a spec file there and, yes, I looked at
it and it appeared to be quite old. :-)

I think, perhaps in a short while, when both the spec file and the
package will be in a better shape, we can add my spec file there, and
point to the package. I can of course send a patch for that (again, when
ready), if you like the idea.

> This also raises for me the question if I can do anything to make
> things easier for other packages as I'm my own Debian package
> maintainer and hence tend to mix up upstream and packaging stuff for
> pure convenience.
>
Nice of you to think about that. :-)

> Things like a more detailed upstream changelog
> (currently the Debian changelog is likely better maintained than the
> upstream changelog) or putting the debian stuff into another branch
> (which would though make my development live less easier as I always
> test stuff by building and installing/updating the Debian package on
> my systems.
> 
I see what you mean, and that would probably be nice. However, I have to
admit, all the issues I'm having (which is, mainly, the thing
about /usr/lib above) are not related to the sources being too much
Debian biased, or too much Debian packaging stuff in the way, or
anything like that.

In fact, for what I've seen up to now, I wouldn't call the sources so
much RPM-unfriendly to the point that any particular action needs to be
taken... Of course, while keeping working on this, I'll let you know
(and, hopefully, send patches), if/when that will reveal no longer
true. :-)

> I currently also tend to relace formerly locally implemented stuff by
> CPAN modules (like using Test::NoTabs in no-tabs.t since recently in
> the git repo) if there are CPAN modules which do the same. I try to
> not use too new modules to allow backporting to Debian Stable. I
> though can imagine that this may make building on distributions with
> less package choice harder.
> 
Not sure... Probably because I'm not much into Perl! :-P
TBH, I found a nasty issue in how Fedora tries to figure out
automatically the dependencies of a package from some Perl modules
(updated package coming soon!), but again, that is probably unrelated
with what you're saying above and, at the same time, was the only issue
related to Perl modules I faced when preparing the package.

So, again, allow me to get into this packaging thing a little more (this
is my first RPM :-P), but for now, I haven't seen anything terrible,
from an "rpmbuild perspective". :-)

> I noticed the line "Requires: debootstrap" in the .spec file. Does
> that refer to Debian's tool "debootstrap" or is the name just a pure
> coincidence?
> 
It's actually Debian's debootstrap, which, luckily enough, is packaged
for Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/debootstrap

I think having the xen-tools package depend on it is reasonable, since
the main purpose and most common use-case of xen-tools is installing
Debian and Debian-alike distros, isn't it? I might be wrong, but I think
I checked and the xen-tools Debian package depends on Debian's
debootstrap too, doesn't it?

Then, as soon as I get some time for it, I plan to give an eye to
packaging rinse too... But that's another story! :-P

Thanks a lot for your interest and feedback,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://xen-tools.org/pipermail/xen-tools-discuss/attachments/20130403/cf1a6d43/attachment.pgp>