Re: Packaging Openstack for Debian: anyone else interested?
On 03/28/2011 03:18 AM, Soren Hansen wrote:
2011/3/27 Thomas Goirand<email@example.com>:
I already started in fact. I took the work made in Ubuntu, and did a
bit of rework (I didn't like the rules.tiny debhelper style with so
many overrides, or the fact that the rules didn't use setup.py...).
For years, Debian Developers have shouted and screamed whenever someone
in Ubuntu added something as benign as a patch system (so that their
indvidual changes would be easier to absorb back into Debian), and here
you are, saying you want to replace our build system altogether for no
good reason? No, I don't think having a couple of overrides is a good
reason to replace the build system, and your suggesting that our
debian/rules doesn't use setup.py really doesn't add much technical
credibility to your criticism, to be quite honest.
Calm down! It is constructive criticism. I really appreciate the work
that you have done so far, and I intend to reuse your work, and share my
thoughts and contributions. It's just a shame that I couldn't chat with
you on IRC over the last days, as I believe it would have avoid such a tone.
If you want to do this on your own, fine. I think it would be sad if we
couldn't make this good example of a "this is how Debian can be a
downstream of Ubuntu" story, but I can't force you to do anything. If
you actually expect to work with us, I suggest you stop assuming we're
idiots who don't know how to packages stuff and start being a courteous
downstream, and let's just say you've not got much of a head start on
Where exactly did you see I wrote you were "idiots"? I wrote that "I
didn't like". This show my *personal tastes*, because I like to
understand everything that happens, and not just trust blindly the
rules.tiny style. Please read again...
The rules.tiny style does useless calls to dh_helper scripts, and makes
it harder to track what's going on (you rely on the "magic" of the
dh_auto* scripts), and also is a bit slower than it should (useless
calls to dh_helper scripts that sometimes aren't needed, like for
installing .desktop files and so on...), which is why I like more the
I would also have appreciate if we could discuss that together, I went
on IRC to chat with you, but I had no luck with that over the last few days.
Moreover, I hope my work wont just be "downstream", I hope we will
constructively collaborate and work together! If what you expect me to
do is just download your work, do a build, and upload blindly to Debian,
that wont work, I'll be of no use. You should instead be happy that I
want to improve things, and on my side, I hope we will both learn from
Or, you know, you could stop building new silos and actually work with
us. There's no technical reason why we couldn't share our packaging
Sure, I 100% agree with that, and I intended to do so.
Also, Openstack is using bzr, and I know only (CVS and) Git. Does
anyone have good pointers to documentation not aimed at newbies, so I
don't waste my time too much?
We tend to point people at http://wiki.openstack.org/LifeWithBzrAndLaunchpad
If you're used to a DVCS, bzr shouldn't be hard to grasp (unless you're
the sort of person who insists on rebasing a lot).
Thanks. I will try to use bzr.
On 03/28/2011 04:03 AM, Stefano Zacchiroli wrote:
> On this respect, I tend to agree with Soren. I believe it's in the
> interest of Debian to avoid unnecessary deviations from the packaging
> it's already been done for other Debian-based distro(s).
I do agree with that, and it is my intention to share my changes with
Ubuntu guys as well, and especially with Soren.
But, if I'm not mistaking, there are things that unfortunately *have* to
change, like the Ubuntu package using upstart-job. If I'm not mistaking,
this isn't an option for Debian, is it? Can anyone comment on that,
because I don't know much about upstart... What I know is that just
leaving things the way it was lead to having dpkg willing to remove the
sysv-rc package, which, IMHO, isn't what we want here.
> Even more so, I
> believe it would be in our interest to try to work together, having a
> single packaging team to which all interested parties have access.