Re: pseudo package for upgrades from hamm
Adam Heath wrote:
>I see a problem with all this talk about pseudo packages for upgrades from
>hamm.
>
>These 'pkgs' will have to remain in the system forever. If someone skips
>slink, and goes to potato when that is released, the same problem will occur.
>
>If we ever fix dpkg/dselect/apt to handle a pkg rename, and we can guarantee
>that an old dpkg/dselect/apt will install the new dpkg/dselect/apt, then we
>will be able to remove the pseudo names. But currently, I don't see how this
>is possible.
[the following is all just talk - I don't feel comfortable hacking dpkg
source yet]
We need to add a new field - call it anything you want - I called it
"Was-Part-Of:" in an earlier post, but I'm sure there's a better name than
that - "Previously:" maybe.
Anyway, say slink contains a package 'foobar', version 1.2-3. The
maintainer decides to split it into 'foo' and 'bar' for potato.
In the control files for the foo and bar packages, the maintainer slips in
that aforementioned field:
Package: foo
Version: 1.2-4
Previously: foobar (<< 1.2-3)
... and does the same thing for the bar package. dselect and apt check that
field, check the current version of foobar, and based on that, automagically
select the new packages.
Chances are, someone has ripped off my idea ;> and submitted it as a
wishlist bug against dpkg already, so I'll look through the list later and
file a wishlist bug if there isn't one already there.
That is, if noone has any better ideas on how to handle this.
>ps: When is Jason Gunthorpe going to rewrite dpkg? :)
You really want dpkg written in C++? :>
--
Robert Woodcock - rcw@debian.org
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
Reply to: