Re: [vox] Debian + KDE vs. Kubuntu
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox] Debian + KDE vs. Kubuntu
On Mon, 29 May 2006, Scott Ritchie wrote:
> On Wed, 2006-05-24 at 13:36 -0700, Don Armstrong wrote:
> > 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.
That's really trivial to do by changing just the Debian version part
of the version. Furthermore, the nameing scheme that you're using
currently doesn't save you from having to do this either; it just
means that you have to ship multiple .orig.tar.gz's instead of one
with multiple diff.gz's.
> 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.
Most of the changes I saw looked to be of possible utility,
actually... but there were only a few, and they were primarily to
various helper applications that wine ships. In any case, if there are
ones that you noted which were particularly crufty and should be
removed, file bugs against the Debian package so the maintainer knows
to deal with them.
> There's even still mentions of wine.conf in there, which hasn't been
> used for about 5 years now.
Yes; we support upgrades from versions that are that old...
considering how long dapper is supposedly going to be supported for,
that sort of thing isn't exactly uncommon.
> 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
Not the ones that I saw; the way they're split currently is to enable
users to only have the bits of wine that they actually want to use
installed, and consequently only the dependencies that those bits of
wine require installed. Currently, your packages are missing
dependencies, so while they install, a large portion of the
functionality is missing.
Upstream's advice, unfortunatly, is often rather useless when it comes
to the proper way to package, release, and distribute software that
runs on machines in various different configuration states. They
generally think only about installation directly from source using
./configure because that's the method that they use to build and use
their software. [So while upstreams may advise lots of different
things, we've been known to hapily ignore them when it's not in the
best interest of our users.]
> > 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]).
Uh... apt-get (and more importantly dpkg) doesn't do that. You must
have dependencies of installed packages satisfied when the packages
are installed, but upgrades have to examine the dependencies of the
package that will be installed.
Otherwise dependencies wouldn't work at all, and you'd never be able
to upgrade anything at all.
The only thing that won't enable you to upgrade is if you've got
versioned Dependencies on specific packages... but since you don't
actually have any content in those packages, you're breaking versioned
dependencies on them anyway.
Now, it is possible that you forgot to add Provides: libwine;
Replaces: libwine; Conflicts: libwine lines to your control, but
that's your problem, not dpkg's. [See Debian's policy for information
1: For a particulaly common depressing example, check out many
upstreams soname practices...
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
-- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html
Description: Digital signature
vox mailing list