|
Home > Archive > Debian Developers > July 2005 > dummy packages and "Replaces:" field
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
dummy packages and "Replaces:" field
|
|
| Margarita Manterola 2005-06-23, 7:52 am |
| 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 order.
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.
This would mean an important change in all these tools, and I guess
that due to the fact that "Replaces:" was not being honoured up to now
some packages might be abusing it, and that would need to be fixed,
too.
Is there a better solution to this? If there isn't, I think that we
should try to fix this for etch. Even if it means a lot or work, it
would be better than stickying to the dummy packages ugly hack.
--=20
Besos,
Marga
| |
| Steve Greenland 2005-06-23, 6:01 pm |
| On 23-Jun-05, 08:03 (CDT), Margarita Manterola <margamanterola@gmail.com> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Margarita Manterola 2005-06-23, 6:01 pm |
| On 6/23/05, Steve Greenland <steveg@moregruel.net> wrote:
> 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-po...ips.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.
> I think that there have been proposals for a new header that
> accomplishes what you want,=20
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 view=
ed as=20
> worthwhile, given that there's no new functionality. Dummy packages work,=
=20
> 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.
--=20
Besos,
Marga
| |
| John Hasler 2005-06-23, 6:01 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-06-23, 6:01 pm |
| On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote:
> On 6/23/05, Steve Greenland <steveg@moregruel.net> wrote:
>
> The documentation for this is in the Debian Policy:
> http://www.debian.org/doc/debian-po...ips.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
| |
| Margarita Manterola 2005-06-23, 6:01 pm |
| On 6/23/05, Roberto C. Sanchez <roberto@familiasanchez.net> 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.
>=20
> 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.
--=20
Besos,
Marga
| |
| Manoj Srivastava 2005-06-23, 6:01 pm |
| On Thu, 23 Jun 2005 11:45:26 -0300, Margarita Manterola
<margamanterola@gmail.com> 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.
[vbcol=seagreen]
> 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.
[vbcol=seagreen]
> 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 <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-06-23, 6:01 pm |
| On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote:
> On 6/23/05, Roberto C. Sanchez <roberto@familiasanchez.net> wrote:
>
> 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
| |
| Brian Nelson 2005-06-23, 6:01 pm |
| 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:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2005-06-23, 6:01 pm |
| On Thu, 23 Jun 2005 08:32:35 -0500, Steve Greenland
<steveg@moregruel.net> 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 <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-06-23, 6:01 pm |
| 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:
>
> 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
| |
| Javier Fernández-Sanguino Peña 2005-06-23, 6:01 pm |
| 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!
| |
| Steve Langasek 2005-06-23, 6:01 pm |
| On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote:
> On 6/23/05, Steve Greenland <steveg@moregruel.net> wrote:
[vbcol=seagreen]
> The documentation for this is in the Debian Policy:
> http://www.debian.org/doc/debian-po...ips.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.
[vbcol=seagreen]
> 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
| |
| Simon Richter 2005-06-23, 6:01 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gustavo Noronha Silva 2005-06-24, 7:52 am |
| 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,
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| Ondrej Sury 2005-06-24, 7:52 am |
| 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:
> the
>
> 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 <ondrej@sury.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Margarita Manterola 2005-06-24, 7:52 am |
| On 6/23/05, Steve Langasek <vorlon@debian.org> wrote:
> 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? =20
Which should this new header be? =20
"Substitutes:", "Supersedes:", "Takes-Over:", "Drop-In Replaces:", "Follows=
:" ?
--=20
Besos,
Marga
| |
| Eric Cooper 2005-06-24, 6:00 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Humberto Massa Guimarães 2005-06-24, 6:00 pm |
| ** Eric Cooper ::
> On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote:
> [...]
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Samuelson 2005-06-24, 6:00 pm |
|
[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.
| |
| Hamish Moffatt 2005-06-24, 6:00 pm |
| On Fri, Jun 24, 2005 at 02:13:43PM -0500, Peter Samuelson wrote:
> [Eric Cooper]
>
> 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 <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2005-06-26, 5:54 pm |
| * Margarita Manterola (margamanterola@gmail.com) [050623 16:45]:
> On 6/23/05, Steve Greenland <steveg@moregruel.net> wrote:
[vbcol=seagreen]
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gustavo Noronha Silva 2005-06-27, 5:54 pm |
| Em Sex, 2005-06-24 Ã_s 13:51 +0200, Ondrej Sury escreveu:
>
> 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,
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| Kevin Mark 2005-06-27, 5:54 pm |
| On Sun, Jun 26, 2005 at 10:08:56PM +0200, Andreas Barth wrote:
> * Margarita Manterola (margamanterola@gmail.com) [050623 16:45]:
>
>
> 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$ $$' `$ $ "' `$ $$' `$
$$ $ $$ggggg$ $ $ $ ,$P"" $ $ $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $
`Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Margarita Manterola <margamanterola@gmail.com> writes:
> On 6/23/05, Steve Langasek <vorlon@debian.org> wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-04, 7:50 am |
| Gustavo Noronha Silva <kov@debian.org> writes:
> Em Qui, 2005-06-23 Ã_s 12:39 -0400, Roberto C. Sanchez 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.
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gustavo Noronha Silva 2005-07-04, 7:50 am |
| [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!
--
kov@debian.org: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
| |
| Goswin von Brederlow 2005-07-04, 5:58 pm |
| Gustavo Noronha Silva <kov@debian.org> writes:
> [please don't CC-me, I'm subscribed]
>
> Em Seg, 2005-07-04 Ã_s 11:20 +0200, Goswin von Brederlow escreveu:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|