Daniel Kobras writes (Re: Renaming a package):
On Fri, Jun 09, 2006 at 02:15:06PM +0100, Ian Jackson wrote:
I don't think it this patch is correct as is, but something similar
might not be unreasonable if it had to be turned on with a command
line option.
[Context: When renaming
On Fri, Jun 09, 2006 at 02:15:06PM +0100, Ian Jackson wrote:
Daniel Kobras writes (Re: Renaming a package):
but the alternative patch to dpkg is quite simple (see
below). Alas, it changes current behaviour.
I don't think it this patch is correct as is, but something similar
might
Daniel Kobras [EMAIL PROTECTED] writes:
On Fri, Jun 09, 2006 at 02:15:06PM +0100, Ian Jackson wrote:
Daniel Kobras writes (Re: Renaming a package):
but the alternative patch to dpkg is quite simple (see
below). Alas, it changes current behaviour.
I don't think it this patch is correct
man, 29,.05.2006 kl. 22.00 +0200, skrev Frank Küster:
martin f krafft [EMAIL PROTECTED] wrote:
Sounds like a clean approach, but is there a clean transition?
I doubt you can upload a source package that generates the same
binary package as another source package.
Oh, you can. Until a
Daniel Kobras writes (Re: Renaming a package):
but the alternative patch to dpkg is quite simple (see
below). Alas, it changes current behaviour.
I don't think it this patch is correct as is, but something similar
might not be unreasonable if it had to be turned on with a command
line option
On Sun, Jun 04, 2006 at 11:42:30PM +0200, Vincent Danjean wrote:
Daniel Kobras wrote:
Method B
Package: oldpkg
Depends: newpkg
Files:
/usr/share/doc/oldpkg - /usr/share/doc/newpkg
(and nothing else)
Does not this hit another bug in dpkg ?
It seems that empty
Daniel Kobras wrote:
Method B
Package: oldpkg
Depends: newpkg
Files:
/usr/share/doc/oldpkg - /usr/share/doc/newpkg
(and nothing else)
Does not this hit another bug in dpkg ?
It seems that empty old directories cannot be replaced by a
symlink without special pre/postinst
Daniel Kobras [EMAIL PROTECTED] writes:
On Fri, Jun 02, 2006 at 09:19:42AM +0200, Andreas Fester wrote:
Absolutely. Its also the method I would prefer because it adds minimal
overhead providing the most seamless upgrade. I implemented it for my
package, and the first test succeeded very well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Goswin von Brederlow wrote:
Daniel Kobras [EMAIL PROTECTED] writes:
[...]
Unpacking replacement lincvs ...
Selecting previously deselected package crossvc.
Unpacking crossvc (from .../crossvc_1.5.0-1_i386.deb) ...
(Noting disappearance of lincvs,
Andreas Fester [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Daniel Kobras [EMAIL PROTECTED] writes:
[...]
Unpacking replacement lincvs ...
Selecting previously deselected package crossvc.
Unpacking crossvc (from .../crossvc_1.5.0-1_i386.deb) ...
(Noting disappearance of lincvs,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Goswin von Brederlow wrote:
Andreas Fester [EMAIL PROTECTED] writes:
[...]
Thats how I understand this approach. Since lincvs only contains the
/usr/share/doc/lincvs - crossvc link, and crossvc also contains the
same link, the link will be taken
[...]
Method B
Package: oldpkg
Depends: newpkg
Files:
/usr/share/doc/oldpkg - /usr/share/doc/newpkg
(and nothing else)
Package: newpkg
Replaces: oldpkg
Provides: oldpkg
Files:
(...)
/usr/share/doc/oldpkg - /usr/share/doc/newpkg
Method A relies on
Hi Daniel,
[...]
I did that once in 2003 for dx but hit a different bug then: dpkg would
try to configure oldpkg when it had disappeared already. It worked fine
thats also my experience with current dpkg unstable. See my reply in
the this thread some postings above. The strange thing is that
On Fri, Jun 02, 2006 at 09:19:42AM +0200, Andreas Fester wrote:
Absolutely. Its also the method I would prefer because it adds minimal
overhead providing the most seamless upgrade. I implemented it for my
package, and the first test succeeded very well (amd64 testing/unstable),
but today I
On Thu, Jun 01, 2006 at 11:46:12PM +0200, Daniel Kobras wrote:
On Thu, Jun 01, 2006 at 01:06:20PM -0700, Steve Langasek wrote:
Oooh, Method B is one I haven't seen proposed before in the context of dummy
packages. That looks far more elegant to me than the alternatives. Have
you tested
On Fri, Jun 02, 2006 at 03:05:08PM +0200, Daniel Kobras wrote:
On Thu, Jun 01, 2006 at 11:46:12PM +0200, Daniel Kobras wrote:
On Thu, Jun 01, 2006 at 01:06:20PM -0700, Steve Langasek wrote:
Oooh, Method B is one I haven't seen proposed before in the context of
dummy
packages. That
in
and promote it for etch+1, though.
IMHO it definitely seems worth doing.
IMHOtoo. I liked this solution for renaming a package, because its
quite simple to implement and provides a seamless upgrade.
Even though renaming a package is probably not something which is done
every day, having a clean
On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
. It also gives one common
use case, namely: Replacing an other package that Provides: the same
virtual package.
If you are renaming a package, and keep a dummy package with the old
name, this is *not* the case 7.5.2 talks about. the title is:
,
| 7.5.2 Replacing whole packages, forcing
On Thu, Jun 01, 2006 at 03:15:02PM +0200, Frank Küster wrote:
Daniel Kobras [EMAIL PROTECTED] wrote:
On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
It explains Replaces+Conflicts. It does *not* say create a dummy package
that can't be installed because it depends on the
Daniel Kobras [EMAIL PROTECTED] wrote:
Steve wondered why people suggest package relationships that cause
problems during upgrades. I claimed that policy may well be the source
of the confusion. The fact that you can read different meanings into it
isn't quite the point. Well, actually it
On Thu, Jun 01, 2006 at 01:39:30PM +0200, Daniel Kobras wrote:
On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
I've heard this stated before, but if it was ever true, it's definitely
not
the case with apt (or with britney), and it's not mentioned in policy.
It may
On Thu, Jun 01, 2006 at 01:06:20PM -0700, Steve Langasek wrote:
On Thu, Jun 01, 2006 at 01:39:30PM +0200, Daniel Kobras wrote:
Method B
Package: oldpkg
Depends: newpkg
Files:
/usr/share/doc/oldpkg - /usr/share/doc/newpkg
(and nothing else)
Package: newpkg
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek [EMAIL PROTECTED]
wrote:
Hm, that used to be a magic combination that would let dpkg do the
right thing.
I've heard this stated before, but if it was ever true, it's definitely not
the case with apt (or with britney), and it's not
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy package
Package: newpkg
Replaces: oldpkg
Conflicts: oldpkg
Daniel Kobras [EMAIL PROTECTED] wrote:
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy package
Package: newpkg
On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy
Steve Langasek [EMAIL PROTECTED] writes:
On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
Package: oldpkg
Depends:
Hi,
Andreas Fester schrieb:
I create a new package with the new name which will
get uploaded to the NEW queue. This package replaces the
old package and conflicts with the old package:
Replaces: oldPackage
Conflicts: oldPackage ( firstVersionOfNewPackage)
IIRC the correct way to do that is
On Tue, May 30, 2006 at 10:23:44AM +0200, Simon Richter wrote:
Andreas Fester schrieb:
I create a new package with the new name which will
get uploaded to the NEW queue. This package replaces the
old package and conflicts with the old package:
Replaces: oldPackage
Conflicts: oldPackage (
Hi,
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy package
Package: newpkg
Replaces: oldpkg
Conflicts: oldpkg
Description: ...
*NO* *NO* *NO* *NO* *NO*. Look closely at the package relationships you've
specified. Why would you upload a package
Hi
On Tue, 30 May 2006 11:22:51 +0200
Simon Richter [EMAIL PROTECTED] wrote:
Hi,
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy package
Package: newpkg
Replaces: oldpkg
Conflicts: oldpkg
Description: ...
*NO* *NO* *NO* *NO* *NO*. Look
Simon Richter [EMAIL PROTECTED] writes:
Hi,
Andreas Fester schrieb:
I create a new package with the new name which will
get uploaded to the NEW queue. This package replaces the
old package and conflicts with the old package:
Replaces: oldPackage
Conflicts: oldPackage (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for all your answers, my package successfully transformed
to its new name with apt-get dist-upgrade in my test environment :-)
One last question: would it be safe to say
Architecture: all
in the dummy transition package since it does not
* Andreas Fester [Tue, 30 May 2006 21:42:27 +0200]:
One last question: would it be safe to say
Architecture: all
in the dummy transition package since it does not contain
any architecture specific files anymore, or is it better to
leave it as it is with Architecture: any to create
On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
Steve Langasek schrieb:
Package: oldpkg
Depends: newpkg
Description: transitional dummy package
Package: newpkg
Replaces: oldpkg
Conflicts: oldpkg
Description: ...
*NO* *NO* *NO* *NO* *NO*. Look closely at the package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
this has already been discusses some times, but
since this is a new situation for me I want to be
sure that it is still true and that I handle it properly :-)
Problem:
Upstream application (non-library) has changed its name.
I want to
Andreas Fester wrote:
Is this the correct approach? Anything I missed?
I think the usual way is to provide the dummy binary package immediately
from the new source package and file a bug for removal of the old source
package.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
also sprach Andreas Fester [EMAIL PROTECTED] [2006.05.29.2114 +0200]:
Replaces: oldPackage
Conflicts: oldPackage ( firstVersionOfNewPackage)
Also: Provides: oldPackage, so that it can still satisfy
(non-versioned) dependencies.
But yeah, seems like the right way to do things.
--
Please do
also sprach Thomas Viehmann [EMAIL PROTECTED] [2006.05.29.2122 +0200]:
I think the usual way is to provide the dummy binary package
immediately from the new source package and file a bug for removal
of the old source package.
Sounds like a clean approach, but is there a clean transition?
I
* martin f krafft [Mon, 29 May 2006 21:26:41 +0200]:
I doubt you can upload a source package that generates the same
binary package as another source package.
You definitely can, and TTBOMK it does not even need NEW if the source
package that starts shipping it already existed.
--
Adeodato
On Mon, May 29, 2006 at 09:26:41PM +0200, martin f krafft [EMAIL PROTECTED]
wrote:
also sprach Thomas Viehmann [EMAIL PROTECTED] [2006.05.29.2122 +0200]:
I think the usual way is to provide the dummy binary package
immediately from the new source package and file a bug for removal
of the
martin f krafft [EMAIL PROTECTED] writes:
also sprach Thomas Viehmann [EMAIL PROTECTED] [2006.05.29.2122 +0200]:
I think the usual way is to provide the dummy binary package
immediately from the new source package and file a bug for removal
of the old source package.
Sounds like a clean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
martin f krafft wrote:
also sprach Andreas Fester [EMAIL PROTECTED] [2006.05.29.2114 +0200]:
Replaces: oldPackage
Conflicts: oldPackage ( firstVersionOfNewPackage)
Also: Provides: oldPackage, so that it can still satisfy
(non-versioned)
martin f krafft [EMAIL PROTECTED] writes:
also sprach Thomas Viehmann [EMAIL PROTECTED] [2006.05.29.2122 +0200]:
I think the usual way is to provide the dummy binary package
immediately from the new source package and file a bug for removal
of the old source package.
Sounds like a clean
martin f krafft [EMAIL PROTECTED] wrote:
also sprach Thomas Viehmann [EMAIL PROTECTED] [2006.05.29.2122 +0200]:
I think the usual way is to provide the dummy binary package
immediately from the new source package and file a bug for removal
of the old source package.
Sounds like a clean
46 matches
Mail list logo
