[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: APT broken ?



On Sun, 5 Apr 1998, Dale Scheetz wrote:

> > > 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.

I suggest you read Tom's nice guide on this subject,
   http://www.debian.org/~jgg/deity/dpkg-tech

Hold is not valid in the last field and is obsolete in the middle field
(AFAIK). It belongs in the first field.

> 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.

A package will only satisfy dependancies if it is unpacked or installed.
A package that is unpacked will be configured.
A package that is configured must have met dependancies.

If any of the above 3 fail then APT declares your system broken and will
not continue [loosely]. The checks are applied to all installed packages,
no relavent dependancy escapes it's notice and there is no way to tell it
to ignore any of them. [perhaps in future]

Hold has -NOTHING- to do with dependancies. 
Hold does not describe the state of a package.
Hold is a FLAG that indicates the packaging system should not change the
version of a so flagged package.

Manoj has what he wants, which is what dselect used hold for.

> No! Just make sure that held packages get their dependencies satisfied and
> satisfy dependencies just like packages that are not held.

Held has nothing to do with the dependancy mechansim and dependancy
correctness checks are applies to all packages irregardless of hold so you
already have the above.
 
> 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.

First, the status field would read "hold ok unpacked", and secondly apt
will complain if it's dependancies are unmet (no matter what you do) and
will always attempt to configure it (no matter what you do).

This is required because if someone uses APT to install a package and it
does not install correctly it must be able to go back and fix it. Turning
that off removes important functionality.

> 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.

Then you already have what you want because hold is implemented correctly.
I will say again -> hold has nothing to do with dependancies. It mearly
creates packages that cannot change version. Which in turn implies things
about other packages that depend on it and it's dependants as well
[because no package may have unmet dependancies].

Hold cannot be used to create 'equiv' packages
Hold cannot be used to pretend the package is installed
Hold cannot be used to prevent configuration
Hold cannot be used to disable checks on the packages dependancies

If you want to do any of the above 4 things then hold is not the right
thing - it never meant any of the above 4.

> 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.

Which is what I have been trying to say, you keep insisting that hold
should control dependancies somehow.

I really don't understand what you want anymore. This entire discussion
started because you said you did not like that APT demanded that all
packages that are installed have met dependancies - hold is NOT a
soltution to lifting that restriction and never was.

Jason


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: