Re: [RFS] crystalcursors and kde-icons-nuovext
On Monday 17 October 2005 18:00, Bastian Venthur wrote:
> Christoph Haas wrote:
> > Okay. Just keep in mind that you cannot change the orig.tar.gz which
> > is currently in Debian. You can only provide new *.diff.gz files for
> > the same upstream tarball. So it's more a todo when your upstream
> > releases a new version.
>
> Ooops. This is not good.
>
> There is already a new upstream version (1.5) but with this version,
> upstream changed the license from GPL to CC with the bad "non
> commercial" clause -- so it's not very likely that I'll ever find a
> sponsor for this (nonfree) version. If upstream does not change his
> mind, I guess debian will only see 1.1 in the archive and so there won't
> be a "new upstream" anymore.
>
> Is it really not possible to provide a new orig.tar.gz (eg by removing
> the old one)? I mean my old version was really crappy and I don't want
> to leave this package in this state forever.
No. I even had this problem with a security upload of a package where the
upstream left bits and pieces of his own attempt to debianize the package
in (.../debian/...) which collided with our work. We had to deal with it
and wait for a new upstream release. You have no (realistic) chance to get
a new orig.tar.gz of the same upstream version into Debian.
So the more or less common workaround is to increase the revision number
(see
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
to make the FTP upload servers think it's a new upstream release. You can
use a higher epoch number (although you will probably regret that) or
increase the upstream version (although that's bad, too, since that invents
a version that does not exist).
In your case I'd leave it like it is and use your tidying up work for the
next upstream release.
> I've just played around with epochs. I tried to change the version to
> 1:1.1 but this does not work. I sniffed the sources of some other
> packages with epochs and saw, that they don't include the epoch in the
> filename.
That's right. The epoch is just there as an override for the package
management system to tell certain version numbers apart. You will not see
it in file names. Increasing the epoch should have worked though.
> My last desperate attempt was be to change the upstream version from 1.1
> to 1.1.0 -- would this be acceptable?
Yes, that sounds like a rather good idea. Doesn't look too ugly and tricks
the version comparison system. :) If you don't know it already... see the
man page for "dpkg". There is a nice option called "--compare-versions"
which allows you to find out whether a revision is newer than another one.
> Even if the package is not uploadable due the new orig.tar.gz -- could
> you please take a look at my other changes in this package?
Sure. Just one issue:
mv $(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/CHANGELOG
$(CURDIR)/debian/$(PACKAGE)/usr/share/doc/$(PACKAGE)/changelog
I suggest you rather use dh_installchangelogs for that. Please see its man
page. (That means also removing the debian/docs file.)
Everything else looks like I had expected it. If you are happy with
increasing the version from 1.1 to 1.1.0 and nobody else objects (I never
had such a special case) that package would be okay for me.
Cheers
Christoph
--
~
~
".signature" [Modified] 1 line --100%-- 1,48 All
Reply to: