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,
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
[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
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
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
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
* 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
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 =
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
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.
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:,
** 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:,
[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
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
Hi!
As you all know, dummy packages are an ugly hack. They require
maintainers to do an unnecesary upload and mean that we need to keep
an unuseful package in the archive just to be able to replace the old
package.
Even if dummy packages fulfill their mission, I believe better
solutions are in
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
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]
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:
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
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
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
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
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
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
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.
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
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
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
28 matches
Mail list logo
