[vox] Debian + KDE vs. Kubuntu

[Scott Ritchie]

On Wed, 2006-05-24 at 13:36 -0700, Don Armstrong wrote: 
> 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.]
>  

The trouble with that scheme is we could easily come out with a new
ubuntu version that was alphabetically before dapper.  If the next
release were "chippy", for instance, the naming scheme would have to be
changed again to make the chippy package a later version than the dapper
one.

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

I just went exhaustively through the diff file, and it seems like a vast
majority of the changes to the wine source code itself were obsolete
cruft from about 2 years ago or worse.  There's even still mentions of
wine.conf in there, which hasn't been used for about 5 years now.  There
were quite a few changes in the debian package, but most of this was
just due to problems arising from the confusing splitting the debian
package does in the first place (against the advice of upstream.)

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

Sure I do - check out debian/wine.mime in the package, for instance.
Right-clicking an executable to run in Wine works just fine.

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

Ahh, I see what you mean.  I've made the changes in the new version.
Again, thanks.

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

The trouble with that approach is they don't smoothly upgrade from the
old split versions (in Debian or in Ubuntu Hoary).  Again, this is due
to a bug in apt-get (it looks at the current package's depends [wine on
libwine] rather than the package to be installed's depends [libwine on
wine]).


Any other thoughts?


Thanks again,
Scott Ritchie