[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: qemu-kvm (kvm)



Mike Hommey wrote:
On Fri, Oct 16, 2009 at 10:15:46PM +0400, Michael Tokarev wrote:
Giuseppe Iuculano wrote:
Michael Tokarev ha scritto:
I wrote to debian kvm package maintainer several times, I
submitted a bugreport against kvm long time ago, but never
heard back.

So now I'm requesting a sponsor to upload my packages into debian.
You are trying to hijack kvm, this is not the way to do it appropriately.

I'm trying to make it to work.
And to my shame, I don't know how to do that in another way.

Ok, I stand corrected.  This topic is covered by developers-reference.

I already support debian users by maintaining the package
out of debian.

Anyway your package is completely wrong, you only changed the source name, we
can't have the same binary name for two different packages, or two identical
packages with a different name.

Well, saying it's completely wrong is not wise.  It's not wrong.

You named one reason why do you think it's wrong.  Which is its
name.  But this has its reasoning in upstream naming.

As I described in my initial email, initially there were
development snapshots with naming scheme like kvm-$number.
It was nothing but development snapshots.  First stable
release was named qemu-kvm-0.10.0, and it will follow this
naming scheme from now on.

With this, there's no real need to package the development
snapshots anymore.  So kvm-$number _source_ package should
go, and be replaced with qemu-kvm.  Which is exactly what
my version does.

Except there is no such kvm-$number source package. The source package
for kvm is kvm.

It sounds like diff vs diffutils rename.
I tried to avoid this rename, and I think I have a reason for this.
Whole kvm thing is somewhat temporary.  Intention of the project is
to merge back to qemu, and this is what's being done - current
qemu-0.11.0 is close to be able to fully utilize cpu virtualization
extensions.

So a few releases from here, I hope, there will be no kvm or qemu-kvm
packages in debian, only qemu.

Yet I renamed the _source_ package to reflect the upstream name.
I hoped to get best from both worlds, maybe others thinks I picked
worst as a result.

Besides, I asked about this on #debian-devel several times, because
it wasn't an easy solution.

In short: the source naming scheme follows upstream.
Note again that as of lenny, there was _no_ single
stable release of kvm.

As of with naming scheme of kvm _binary_ package, I left
it the way it was before, to avoid further confusion.
Which is enough already, due to the fact that kvm is
a patched version of qemu.

And that is called highjacking.

Ok.  I see what you both mean now.  And I didn't know what
I'm trying to do called this way.  Sure thing it's not a
welcome action.

Still declaring the package as "completely wrong" is wrong.

And there is a procedure described in the reference for that
as well.  I'll go from there.

But I've another question here.

There's a ton of bugs listed for kvm package currently.
Some are fixed by this version (or by prior versions),
some become moot points, some are valid still but
questionable.

What I don't understand completely is what will be with
all those bugs in case the package gets orphaned or
hijacked?  Can it all be "reassigned" to the new package,
to be dealt with in subsequent release(s), so that all
bugs can be found at the same place?

Thanks.

/mjt

kvm is a well-recognized _executable_ name for this
binary, and the fact that it comes from qemu-kvm source
is not an issue.

Also I want to have easy upgrade path from kvm-$num
as in debian now to this qemu-kvm package.

So I'm not quite sure what I missed.  Except of the
"proper way" you mentioned above. Which I still don't
know -- the way I know is to contact the maintainer
and/or submit bugreports.  I did both, starting about
half a year ago, but to no avail.

You obviously missed how debian package maintenance works, which is
something you should know as someone who applied to be DD.

Mike


Reply to: