Re: APT broken ?
On Sun, 5 Apr 1998, Jason Gunthorpe wrote:
>
> On Sun, 5 Apr 1998, Dale Scheetz wrote:
>
> > > > I don't see what is wrong with this, as it falls within original
> > > > definitions of the behaviour.
> > >
> > > How so?
> > >
> > > Installed - Means that the package is unpacked and configured and is in a
> > > good state
> > >
> > But for many packages, unpacking them is sufficient to satisfy the
> > dependency. I believe cpp is one of those. Once it is unpacked gcc will
> > work.
>
> Unpacked is not at all the same as installed - they are completely
> different states. A package is not considered 'Installed' until it's
> scripts run successfully.
A strict interpretation of the "definitions" as understood by dpkg leads
to this statement, but the fact is that gcc's dependence on cpp has been
satisfied the instant that cpp is unpacked and the necessary binary is in
the file system. This fact is used in other cases, why ingore it here?
>
> > suspect that the cleanest way to deal with it in the status file is to
> > declare the package as "installed ok hold" so dpkg/APT doesn't try to
>
> Erm what you are suggesting sounds more like "hold ok unpacked".
>
As far as I know, "hold" is only valid in the last field.
> Incendently, the Status: line is fairly important to the functioning of
> dpkg. I will -NOT- change it in any fashion or change the meanings of any
> of the terms. There is simply too much risk.
No one is asking you to.
>
> Hold means do not try to change that packages state. That is all it means,
> nothing more, nothing less. If you hold an uninstalled package it will
> never automatically install it. If you hold an installed package it wil
> never try to remove it or upgrade it. If it is in transition state then it
> will be pushed to next closest final state.
>
I might argue that a transition state should be left alone as well, but
will settle for you view, as it gives me all I need.
> The only thing hold means to dpkg is that when doing a recursive directory
> scan it will not install that package. (APT's interpitation is an
> extrapolation of that behavior)
All Manoj and I are trying to make sure of is that these held packages
will still satisfy dependencies for other packages and will still have
their dependencies satisfied by the other packages it needs.
>
> > Why clutter what you are designing when there is an adequate mechanism
> > already available. The desire to know all the details of the install, by
> > the package manager, is likely to yield an inflexible system. I'm just
> > looking for more "freedom" and flexibility.
>
> Okay, so to do this you want me to change the meaning of Hold to extend to
> dependancy relations and butcher the meaning of unpacked or installed to
> mean 'maybe installed'?
No! Just make sure that held packages get their dependencies satisfied and
satisfy dependencies just like packages that are not held.
>
> What about people who want to use hold for it's original purpose? Those
> who simply want a package to never be installed or upgraded. The new
> definition mucks up their system, they could have an unpacking accident
> and then apt will magically consider the package as OK and not issue any
> warnings that their system is hosed. Certainly not what why want.
>
I've never asked that APT do anything is this case, but if I purposefully
unpack a package and don't configure it, and then mark the status file as
"install ok hold", I expect APT to treat it as though it were completely
installed and able to satisfy dependencies. It is my responsibility if
things don't work.
> A new flag is a much better alternative and does not require the messy
> unpacking but not configuring hack that abusing hold does. It also
> preserves the existing meaning of hold which is just as important.
>
You seem to want to "keep control of the situation" even in situations
where APT can never know what the "right" thing might be. I have asked for
no changes in the functioning of hold, only that it act as previously
described with respects to honoring depends for and by the held package.
If dependency information is ignored for held packages then the hold
feature isn't implemented appropriately for its "legal" use, much less the
side-step I would use it for as well.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: