Re: procps_1.09-0_i386.changes INSTALLED
[I'm cc'ing this private email to debian-devel so that everyone is
aware of this issue. I assume Helmut won't mind.]
On Sun, 6 Oct 1996, Helmut Geyer wrote:
> The changes file clearly indicated that this is an experimental package.
>
> It definitely shouldn't go into unstable. the
> procps-1.01a-3 package is meant for unstable and if there are no
> problems with it for stable. The 1.09 package is meant for testing now.
> Doesn't work the Distribution: experimental field in the changes file?
>
> I uploaded a correct version of procps_1.01a.orig.tar.gz to master
> right now.
Ian had a similiar issue with dinstall a month or so ago, and I
explained it to him. The gist is that it's quite difficult to install
packages in multiple places without making lots of mistakes.
If you truly have a need for an experimental procps, I suggest you name
it exp-procps or something like that, and have it conflict with
procps.
---cut---
On Mon, 9 Sep 1996, Ian Jackson wrote:
> When I uploaded debiandoc-sgml 1.0.5 the .changes file below was
> included. As you can see it said `Distribution: unstable'. However,
> I see that the package has not been installed into unstable but into
> project/experimental. It should be moved, and steps should be taken
> to stop the problem from recurring.
I will move debiandoc-sgml, but dinstall's behavior was correct.
The override files instructed dinstall to put debiandoc-sgml into
experimental, overriding what was in the .changes file.
This problem will recur whenever a package moves from one section or
distribution to another. dinstall cannot handle this case because it
doesn't know where to look for the older version to unlink it.
Instead it assumes that the .changes file listed incorrect sections and
distributions (a fairly frequent occurrence actually), and installs the
package into the old location. Since package movements are much more
rare than .changes files with incorrect locations, dinstall's assumption
is the right one.
dinstall could, alternatively, require human intervention in this case.
But it was written to run as automatically as possible. It will make a
recoverable error, which is usually the right thing to do, rather than
do nothing at all.
A third alternative is to turn the `Override file lists section as
... overriding your choice of ...' message into an error, so the package
would get rejected. But this is illogical as it would require MORE
intervention: maintainers would be forced to reupload new .changes
files and the distribution maintainer would still have to edit the
override file.
So I would like to close this bug, as it's not a bug. Of couse, you
may be able to suggest a fourth alternative which is better.
Guy
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: