Re: dummy packages and Replaces: field
Gustavo Noronha Silva [EMAIL PROTECTED] writes:
Em Qui, 2005-06-23 Ã s 12:39 -0400, Roberto C. Sanchez escreveu:
OK. That is what I am looking for. I want to completely replace the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
See ya,
A source package can build binary packages with different versions.
E.g. icewmcp 1.0-1 source could build:
icewmcp 1.0-1
iceme 1.0.0-12.1
iceperf 1:1.2-3
Absolutely no problem with that.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
Margarita Manterola [EMAIL PROTECTED] writes: On 6/23/05, Steve Langasek [EMAIL PROTECTED] wrote: Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Changing the meaning of existing fields is far worse than changing policy to accomodate a new field. Ok, agreed. So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? baz Conflicts/Replaces/Provides: foo Then and only then can baz be installed automaticaly as upgrade of foo (given that foo no longer exists). To achieve this change, we would need: * A policy change: include the new header and explain the meaning, in Section 7. That would be much cleaner than using a combination of existing headers to mean the same. * A change in dpkg's behaviour: interpret this header as a Replaces+Conflicts case, where all the files in the old package are replaced by the new package. Replaces and Conflicts can still be used to express this. That way old dpkg/apt can still install the new packages (but won't automaticaly). That is rather important. * A change in apt/aptitude/synaptic/etc behaviour: install the program that has the new header when appropiate. It's a long way to go, I guess that it should start in dpkg, right? Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Supersedes sounds good. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
[please don't CC-me, I'm subscribed] Em Seg, 2005-07-04 às 11:20 +0200, Goswin von Brederlow escreveu: A source package can build binary packages with different versions. E.g. icewmcp 1.0-1 source could build: icewmcp 1.0-1 iceme 1.0.0-12.1 iceperf 1:1.2-3 Simply by having a Version field for the binary package on debian/control? I'd like to see an example of that being handled, could you be so kind as to point a concrete example so I can learn this better? Thanks! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org signature.asc Description: This is a digitally signed message part
Re: dummy packages and Replaces: field
Gustavo Noronha Silva [EMAIL PROTECTED] writes: [please don't CC-me, I'm subscribed] Em Seg, 2005-07-04 Ã s 11:20 +0200, Goswin von Brederlow escreveu: A source package can build binary packages with different versions. E.g. icewmcp 1.0-1 source could build: icewmcp 1.0-1 iceme 1.0.0-12.1 iceperf 1:1.2-3 Simply by having a Version field for the binary package on debian/control? I'd like to see an example of that being handled, could you be so kind as to point a concrete example so I can learn this better? Thanks! Simplest one I know is gcc: Package: gcc Source: gcc-defaults (1.21) Version: 4:3.3.5-3 MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
Em Sex, 2005-06-24 às 13:51 +0200, Ondrej Sury escreveu:
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
Only if dummy packages come from same source as icewmcp. If he wants to
avoid epoching he could just create dummy source package... (At least I
think so :-).
Looks even more elegant, indeed.
See ya,
--
[EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov
Debian: http://www.debian.org * http://www.debian-br.org
signature.asc
Description: This is a digitally signed message part
Re: dummy packages and Replaces: field
On Sun, Jun 26, 2005 at 10:08:56PM +0200, Andreas Barth wrote: * Margarita Manterola ([EMAIL PROTECTED]) [050623 16:45]: On 6/23/05, Steve Greenland [EMAIL PROTECTED] wrote: Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Frankly speaking, I prefer a new header better than overloading the semantic of the existing headers. Hi Andi, if the old headers have more than one use case, would it be good to state what they DO mean and DO NOT mean so that if and when a new headers is added, it will be clear why you would want to use the new one and why you SHOULD not use the old one. Cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: dummy packages and Replaces: field
* Margarita Manterola ([EMAIL PROTECTED]) [050623 16:45]: On 6/23/05, Steve Greenland [EMAIL PROTECTED] wrote: Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Frankly speaking, I prefer a new header better than overloading the semantic of the existing headers. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
Em Qui, 2005-06-23 às 12:39 -0400, Roberto C. Sanchez escreveu:
OK. That is what I am looking for. I want to completely replace the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
See ya,
--
[EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov
Debian: http://www.debian.org * http://www.debian-br.org
signature.asc
Description: This is a digitally signed message part
Re: dummy packages and Replaces: field
On Fri, 2005-06-24 at 08:39 -0300, Gustavo Noronha Silva wrote:
Em Qui, 2005-06-23 às 12:39 -0400, Roberto C. Sanchez escreveu:
OK. That is what I am looking for. I want to completely replace
the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
Only if dummy packages come from same source as icewmcp. If he wants to
avoid epoching he could just create dummy source package... (At least I
think so :-).
O.
--
Ondrej Sury [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On 6/23/05, Steve Langasek [EMAIL PROTECTED] wrote: Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Changing the meaning of existing fields is far worse than changing policy to accomodate a new field. Ok, agreed. So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? To achieve this change, we would need: * A policy change: include the new header and explain the meaning, in Section 7. * A change in dpkg's behaviour: interpret this header as a Replaces+Conflicts case, where all the files in the old package are replaced by the new package. * A change in apt/aptitude/synaptic/etc behaviour: install the program that has the new header when appropiate. It's a long way to go, I guess that it should start in dpkg, right? Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? -- Besos, Marga
Re: dummy packages and Replaces: field
On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? [...] Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
** Eric Cooper :: On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? [...] Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) I disagree. This is not economic in terms of # of uploads... forces you to give a new (last) upload for the old package, which would be even larger than the dummy package upload. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
[Eric Cooper] Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) The whole point of the exercise was to get rid of dummy packages. Your proposal requires one. Which is not to say there is no merit in a package tag or field that says this exists only to suck in dependencies, so when it has served this purpose, delete it at leisure. aptitude would presumably transfer the auto-install flag state from the dummy package to anything it depends on, then set the dummy package itself to the auto-installed state, for garbage collection. signature.asc Description: Digital signature
Re: dummy packages and Replaces: field
On Fri, Jun 24, 2005 at 02:13:43PM -0500, Peter Samuelson wrote: [Eric Cooper] Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) The whole point of the exercise was to get rid of dummy packages. Your proposal requires one. Unless there was a way to include these entries in the Packages file (or some other control file) other than dummy packages.. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On 23-Jun-05, 08:03 (CDT), Margarita Manterola [EMAIL PROTECTED] wrote: The one I can think of is honouring the Replaces: field, meaning that when a package states that it replaces another one, apt, aptitude, dselect, and all the others would install it to replace of the old one. That is not what Replaces: means, and changing dpkg to do what you want would break a lot of existing packages that are NOT mis-using it. See the dpkg docs for what Replaces: actually does. Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, but it's never gone anywhere. I suspect that the effort has not been viewed as worthwhile, given that there's no new functionality. Dummy packages work, and have the advantage that it's very clear what is going on. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
Steve Greenland writes: Dummy packages work, and have the advantage that it's very clear what is going on. Users often find them very confusing. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On 6/23/05, Steve Greenland [EMAIL PROTECTED] wrote: The one I can think of is honouring the Replaces: field, meaning that when a package states that it replaces another one, apt, aptitude, dselect, and all the others would install it to replace of the old one. That is not what Replaces: means, and changing dpkg to do what you want would break a lot of existing packages that are NOT mis-using it. See the dpkg docs for what Replaces: actually does. The documentation for this is in the Debian Policy: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2 And basically, what it says is that if a package Replaces: and Conflicts: with another package, the new one is completely replacing the old one. So, when both Replaces: and Conflicts: are there, and it is not a virtual-package, it would trigger apt replacing the package. Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Having the Real-Replaces: or whatever field might be clearer than having a set of nested ifs. And would not cause any problems with packages that are already using the Replaces field for something else. but it's never gone anywhere. I suspect that the effort has not been viewed as worthwhile, given that there's no new functionality. Dummy packages work, and have the advantage that it's very clear what is going on. It's not really _that_ clear to the end user, and dummy packages are an unnecesary hassle in the archive. They work, yes, but they're an ugly hack, and I think we can do better than that. -- Besos, Marga
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote: On 6/23/05, Steve Greenland [EMAIL PROTECTED] wrote: The one I can think of is honouring the Replaces: field, meaning that when a package states that it replaces another one, apt, aptitude, dselect, and all the others would install it to replace of the old one. That is not what Replaces: means, and changing dpkg to do what you want would break a lot of existing packages that are NOT mis-using it. See the dpkg docs for what Replaces: actually does. The documentation for this is in the Debian Policy: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2 And basically, what it says is that if a package Replaces: and Conflicts: with another package, the new one is completely replacing the old one. So, when both Replaces: and Conflicts: are there, and it is not a virtual-package, it would trigger apt replacing the package. OK. How would I make use of this. I was going to adopt iceme and icepref, but then I saw that they are abandoned upstream. They have become modules of IceWMCP. I am going to package IceWMCP with the intent that it replace iceme and icepref. Someone recommended that I use dummy packages of iceme and icepref that depend on icewmcp. But, if I also make icewmcp Replace and Conflict with iceme and icepref, will that not cause problems (since the new dummy versions of iceme and icepref will depend on icewmpc)? The thing is, I would like to be able to package icewmcp and request the removal of iceme and icepref and know that all users with iceme and icepref currently installed will get notified that icewmcp is the upgrade they need. Maybe I misunderstand? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpguzZ1tJqUL.pgp Description: PGP signature
Re: dummy packages and Replaces: field
On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: OK. How would I make use of this. I was going to adopt iceme and icepref, but then I saw that they are abandoned upstream. They have become modules of IceWMCP. I am going to package IceWMCP with the intent that it replace iceme and icepref. Someone recommended that I use dummy packages of iceme and icepref that depend on icewmcp. But, if I also make icewmcp Replace and Conflict with iceme and icepref, will that not cause problems (since the new dummy versions of iceme and icepref will depend on icewmpc)? Well, of course, you cannot adopt both methods. Either you use the dummy package method or you use the Replace and Conflict method. Also, my suggestion is not the answer to a problem, just a starting point to think about it. It has been brought to my attention than Replaces: and Conflicts: are not enough, Provides: is also needed. And for that, we would need a Provides that supports versions, which is not currently the fact. So dpkg would need to be fixed first. -- Besos, Marga
Re: dummy packages and Replaces: field
On Thu, 23 Jun 2005 11:45:26 -0300, Margarita Manterola [EMAIL PROTECTED] said: And basically, what it says is that if a package Replaces: and Conflicts: with another package, the new one is completely replacing the old one. So, when both Replaces: and Conflicts: are there, and it is not a virtual-package, it would trigger apt replacing the package. But the semantics also are that the _user_ selects the new package, and all the conflict/replace/provide does is that dpkg does not complain. I would be very surprised if apt were to change these semantics out from under me. Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Having the Real-Replaces: or whatever field might be clearer than having a set of nested ifs. And would not cause any problems with packages that are already using the Replaces field for something else. Umm , changing the existing semantics is far worse than the problem -- if it is a problem -- you are trying to solve. Also,if apt immediately tries to replace the old package with the new one (with no dummy package to ewase the transition), then in Sid such an upgrade would be broken until the last package with a versioned depends on the old one (provides are unversioned). Dummy packages are small, cost little, and allow for a transition period where people can start using the new package, and still gives depending packages (even those with versioned depends) a window to change their dependencies over to the new package, without stalling out the transition. Until these technical issues are dealt with, I can't see how dummy packages can be done away with. but it's never gone anywhere. I suspect that the effort has not been viewed as worthwhile, given that there's no new functionality. Dummy packages work, and have the advantage that it's very clear what is going on. It's not really _that_ clear to the end user, and dummy packages are an unnecesary hassle in the archive. They work, yes, but they're an ugly hack, and I think we can do better than that. What, 239 packages out of some 16000 total? What exactly is the problem? This is a miniscule number, and the disk requirements for a dummy package is negligible. Now, novice users can possibly be puzzled, but the description usually says that the packages is a dummy used for upgrades, install package foo instead, and you can remove this package. Hardly rocket science to understand what this means, neh? manoj -- Which is worse: ignorance or apathy? Who knows? Who cares? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote: On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: OK. How would I make use of this. I was going to adopt iceme and icepref, but then I saw that they are abandoned upstream. They have become modules of IceWMCP. I am going to package IceWMCP with the intent that it replace iceme and icepref. Someone recommended that I use dummy packages of iceme and icepref that depend on icewmcp. But, if I also make icewmcp Replace and Conflict with iceme and icepref, will that not cause problems (since the new dummy versions of iceme and icepref will depend on icewmpc)? Well, of course, you cannot adopt both methods. Either you use the dummy package method or you use the Replace and Conflict method. Right. However, what I would like is to be able to do it *without* using dummy packages. I think that what I want is not possible without dummy packages. That is where I see a problem. The current Replaces/Conflicts mechanism doesn't handle it all well. I agree a change that makes it work more elegantly would be nice. It would also help to eliminate a number of dummy and transitional packages that exist for no other reason than to be a hacky work around for replacement of obselete packages. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpciUQpcigMJ.pgp Description: PGP signature
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 12:02:44PM -0400, Roberto C. Sanchez wrote: On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote: On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: OK. How would I make use of this. I was going to adopt iceme and icepref, but then I saw that they are abandoned upstream. They have become modules of IceWMCP. I am going to package IceWMCP with the intent that it replace iceme and icepref. Someone recommended that I use dummy packages of iceme and icepref that depend on icewmcp. But, if I also make icewmcp Replace and Conflict with iceme and icepref, will that not cause problems (since the new dummy versions of iceme and icepref will depend on icewmpc)? Well, of course, you cannot adopt both methods. Either you use the dummy package method or you use the Replace and Conflict method. Right. However, what I would like is to be able to do it *without* using dummy packages. I think that what I want is not possible without dummy packages. That is where I see a problem. The current Replaces/Conflicts mechanism doesn't handle it all well. It's not designed nor intended to do what dummy packages do. It's meant to be used in cases where two packages don't coexist, so installing one automatically removes the other. I agree a change that makes it work more elegantly would be nice. Not to the Replaces/Conflicts behavior. You must introduce a new field--see #33344 or #77325. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On Thu, 23 Jun 2005 08:32:35 -0500, Steve Greenland [EMAIL PROTECTED] said: I think that there have been proposals for a new header that accomplishes what you want, but it's never gone anywhere. I suspect that the effort has not been viewed as worthwhile, given that there's no new functionality. Dummy packages work, and have the advantage that it's very clear what is going on. OK. Heres trhe thing. Suppose there is a package foo, now not being developed. There is a package baz that depends on it. There is a new package foo, that in some sense provides a replacement. Let us consider a couple of scenarios: a) bar is a drop in replacement -- it uses the same config, for example, it hs the same functionality, and is better than foo, has support, security fixes, what have you -- and in all cases should be installed on any machine on which foo was installed. This is currently done using dummy packages, and it allows for depending packages a window of time to upgrade dependencies. With a dummy package foo; baz can continue to depend on foo during the transition, while the user is actually using bar, the transition is not stalled. Even if baz has a versioned dependency on foo. This window for transition is critical. b) bar is _not_ a drop in replacement -- perhaps it has different config files, subtly different behaviour, and you do not want the system to automatically replace foo without a human decision to do so. (say, kinda like the MTA's in debvian, that all conflict, replace, and provide the virtual mail-transport-agent package). In this case, one does _not_ use a dummy package, one uses conflict, replace, and provide (and perhaps a NEWS.Debian in a new version of foo), and works with dependent packages to depend on foo | bar, if at all possible (which it may not be, given bar is not a drop in replacement for foo). It would be better if bar could have a versioned provides, but hey, one works with what one has. In no way should support for option (b) be dropped, you certainly should not change the semantics of option (b) to work the same as option (a). And any replacement for option (a) should continue to provide the window for the transition (a flag day changeover usually does not work). manoj -- Some rise by sin and some by virtue fall. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 07:22:28PM +0300, Brian Nelson wrote: On Thu, Jun 23, 2005 at 12:02:44PM -0400, Roberto C. Sanchez wrote: Right. However, what I would like is to be able to do it *without* using dummy packages. I think that what I want is not possible without dummy packages. That is where I see a problem. The current Replaces/Conflicts mechanism doesn't handle it all well. It's not designed nor intended to do what dummy packages do. It's meant to be used in cases where two packages don't coexist, so installing one automatically removes the other. OK. That is what I am looking for. I want to completely replace the two packages that cannot coexist with the new icewmcp package. Currently, I must use dummy packages for that, correct? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpEYGABfAHf5.pgp Description: PGP signature
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 10:47:00AM -0500, Manoj Srivastava wrote: What, 239 packages out of some 16000 total? What exactly is the problem? This is a miniscule number, and the disk requirements for a dummy package is negligible. Now, novice users can possibly be (...) I guess your count is based on 'apt-cache search dummy'. Sorry, unfortunately that will not provide you with a full list for several reasons: 1.- there are packages that include 'dummy' in their description which are not provided for transitional reasons (i.e. java-common) 2.- there are packages labeled as dummy that are in fact used to track versioned packages (i.e. libapache-mod-python). Users should not remove these, they are not transitional packages either. 3.- there are dummy packages which do not use 'dummy' in their description but use something else instead (look at zope-tinytable or try searching for 'transitional'). One of the main problems looking for these packages is that there is no standard _description_ for them. That makes it difficult for us to find and clean them between releases [1] and for system administrators to find which ones are present in their system and remove them after an upgrade. Regards Javier [1] I did a 'dummy' hunt before sarge which resulted in some dummy packages being removed from sarge which were created to ease potato-woody upgrades! signature.asc Description: Digital signature
Re: dummy packages and Replaces: field
On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote: On 6/23/05, Steve Greenland [EMAIL PROTECTED] wrote: The one I can think of is honouring the Replaces: field, meaning that when a package states that it replaces another one, apt, aptitude, dselect, and all the others would install it to replace of the old one. That is not what Replaces: means, and changing dpkg to do what you want would break a lot of existing packages that are NOT mis-using it. See the dpkg docs for what Replaces: actually does. The documentation for this is in the Debian Policy: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2 And basically, what it says is that if a package Replaces: and Conflicts: with another package, the new one is completely replacing the old one. So, when both Replaces: and Conflicts: are there, and it is not a virtual-package, it would trigger apt replacing the package. But there is nothing in policy that says you can't have multiple packages that Conflicts: and Replaces: the same package. How is apt supposed to know which of these packages to install as the replacement? Also, the Conflicts: and Replaces: fields are frequently overused and abused in packages currently. Adding an additional meaning will only make the problem worse. Is there a better solution to this? I think that there have been proposals for a new header that accomplishes what you want, Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Changing the meaning of existing fields is far worse than changing policy to accomodate a new field. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: dummy packages and Replaces: field
Hi, Roberto C. Sanchez schrieb: Someone recommended that I use dummy packages of iceme and icepref that depend on icewmcp. But, if I also make icewmcp Replace and Conflict with iceme and icepref, will that not cause problems (since the new dummy versions of iceme and icepref will depend on icewmpc)? I might be horribly wrong with this, but I dimly remember that in the case that the dummy package depends on a package that conflicts and provides the dummy, apt will not upgrade with upgrade and switch over to the new package on dist-upgrade. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
