[vox] Debian + KDE vs. Kubuntu

[Scott Ritchie]

On Tue, 2006-05-23 at 23:14 -0700, Don Armstrong wrote:
> 
> Ah, right.
> 
> Couple tips really quick though:
> 
> 1: You've repacked the original tarball twice.[1] [Just use a symlink
> if that's what you actually want to change the upstream version;
> dpkg-source -b will follow it and do the right thing.]

If you're referring to how there are two different packages (one for
dapper and one for breezy), this is to make things easier when a new
release comes out, as I often can't release an update for both versions
simultaneously.  Relying on a symlink would break one of those versions
when the package using the original gets updated, as well as being extra
work for not a whole lot of benefit.

> 
> 2: Using a ~ as an addition to the upstream version is just confusing,
> as the versions no longer segregate as you might expect. FE, a
> 0.9.9-0ubuntu1 package will replace the 0.9.9~winehq1~ubuntu~6.06; if
> that's what you want to happen, use 00winehq or similar (as you
> mentioned in a changelog); this also means that you can differentiate
> (if it's even required) between the two ubuntu versions with a simple
> changelog modification and a rebuild.
> 

I'm a bit confused as to what's confusing you.  The use of the ~'s is
very intentional, to make upgrading from the winehq version to the
official Ubuntu version easier.

With the current naming system, things upgrade smoothly and you can tell
which version the package was built for.  

> 3: You're using rpath in the generated binaries. This is a bad idea,
> because it adds random paths to the library search path which may not
> be present on end users systems.
> 

I could be mistaken, but I think that's only a problem if they're not
using Ubuntu or our shared libraries end up moving for some reason (such
as a major upgrade) - but that's also when the package will get updated.

> 4: It looks like you're missing a lot of the bug fixes that were added
> to the Debian packages between when you forked them a year and a half
> ago and now... you probably want to check them out.
> 

A lot of the older "fixes" actually ended up breaking things as Wine got
updated, which is why the package was started cleanly from scratch.  As
it is now the package is pretty much a clean upstream build.

> 5: You're missing a lot of the configuration that the Debian packages
> give you for free.
> 

What do you mean?  Wine configuration is done automagically these days
with a script that Wine runs when it doesn't detect ~/.wine.  The
default works fine in Ubuntu.

> 6: The Build-Depends: you've got are needlessly fragile; you should
> alternatively depend on the -dev packages that the versioned packages
> provide.
> 

Could you clarify what you mean here?  Some of the build-depends were
made more specific (eg: requiring libicu34-dev rather than either
libicu34-dev or libicu28-dev) to work around bugs in apt-get (namely
that build-source wasn't smart enough to take what's available.)

> 7: You're missing almost all of the Depends: that your packages need
> in order to install correctly. There's a reason why the original
> packages had ${shlibs:Depends} lines in them.
> 

Thanks, that one was easy to forget.

> [You probably also should run lintian on these packages amongst other
> things.]
> 
> You really should fix up at least some of these issues before
> attempting to get this version in Ubuntu.
> 
> 
> Don Armstrong
> 
> 1: dpkg-source needs to be changed to deal with .bz2 tarballs, but
> that's in the pipeline. 

Seriously, thanks for taking the time to look things over, you went out
of your way.

-Scott Ritchie