[vox] Debian + KDE vs. Kubuntu

[Don Armstrong]

On Wed, 24 May 2006, Scott Ritchie wrote:
> 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.

Any time a new version comes out, you just have a new orig.tar.gz, and
you modify the changelog accordingly. There's no problem having
multiple orig.tar.gz's laying about so long as you've got the right
upstream versions in your debian/changelog.

> > 2: Using a ~ as an addition to the upstream version is just
> > confusing, as the versions no longer segregate as you might
> > expect.
> 
> 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.

Right, but the way I'd recommend that you do this instead is using the
following:

0.9.9-00winehq~breezy0 and 0.9.9-00winehq~dapper0 et al. [+ or . will
also work, but ~ is probably best.]
 
> > 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.

The problem is that you're forcing the packages in a major upgrade to
Pre-Depend upon an upgraded version of your package instead of
allowing the upgrade to just happen automatically. Of course, the
rpaths which are actually in the library are $ORIGIN/.. which are
moderately more sane than the usual rpath that libraries carry around
(which often is tied to the directory in which the library was
actually built.]
 
> > 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.

There's been quite a bit of change in the package from pre 0.9.9 to
0.9.11; in general fixing the bugs is part of what it means to release
a version of upstream packages to distributions.
 
> > 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.

For example, you don't include desktop icons, entries into mime info
for ms dos programs, etc.

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

For example:

Package: libicu34-dev
[...]
Replaces: libicu21-dev, libicu28-dev, icu-data, icu-i18ndata
Provides: libicu-dev
Depends: libicu34 (= 3.4.1a-1), libc6-dev | libc-dev
Suggests: icu-doc
Conflicts: libicu21-dev, libicu28-dev, libicu-dev, icu-data, icu-i18ndata

This means that you should have a Build-Depends line that looks
something like:

Build-Depends: libicu34-dev | libicu28-dev | libicu-dev

When libicu is upgraded to libicu35 (or whatever), your package can be
rebuilt against libicu35 with a trivial binNMU instead of requiring
uploads of the package.

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

NP; I started in because I was interested in seeing if you had made
changes that should be brought to the Debian maintainer's attention;
but having started, I thought you should be aware of what you need to
change if you want upgraded packages in Debian. [Which is probably
very similar to the changes required of packages in Ubuntu.]

[You'll note too that your libwine and libwine-dev packages are
totally empty... if that's intentional, then they should probably just
be Provides of the wine package.]


Don Armstrong

-- 
[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21

http://www.donarmstrong.com              http://rzlab.ucr.edu