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

dpkg, aptitude and use of state files (was: Re: Important information regarding upcoming dpkg 1.16.2 upload)



TL;DR: aptitude does keep dpkg/status and apt/extended_states
up-to-date with the *current* state of a package, just like other
software.  Please do not grok pkgstates to determine if something is
installed, etc.

On 18 March 2012 23:16, John D. Hendrickson and Sara Darnell
<johnandsara2@cox.net> wrote:
> Hi,  I like dselect, dpkg, and aptitude.  I have a request.  aptitude should
> import and export
>
>        /var/lib/dpkg/status
>
> At least when asked.  Right now aptitude takes awkwardly and but doesn't
> give back.
>
> It's not just private selections.  Private methods and worse pivate status
> make other programs impossible.
>
> "aptitude : attempts to detect status of  dpkg or dselect"  That's is far
> short of par - noting how sipmle the task of using human readable status as
> save format is.
>
>        /var/lib/aptitude/pkgstatus
>
>        (also it uses pieced avail lists/ instead of unified avail in dpkg/ )
>
> pkgstatus contains incorrect information!  and it codes states "1 3 3 4"
> while using wide text for everything but that.
>

The developer explains (vaguely) why there is not a one-to-one
corelation between dpkg status, aptitude pkgstates, and apt
extended_states:[1]

>> Currently, aptitude stores the held status of packages in some
>> internal database. I am guessing this may be
>> /var/lib/aptitude/pkgstates. Would it not be best if it behaved like
>> apt-get, ie. reading information from /var/lib/dpkg/status?
>
>   No, it wouldn't.  dselect's states are not in general equivalent to
> aptitude's, although they're similar.

Not sure what that means?  Me either, initially.

Aptitude allows the user to mark package changes but leave them for
another session.  So, interactively you can mark several installs,
removals, etc. and then quit, when you start again those changes will
still be remembered and ready to perform.

This is what it tries to store in pkgstates, the user's "intended"
state for the package, not it's actual state.

Except for "hold" (which is a whole bag of fish), the actual, current
state of packages is kept in dpkg and apt files, just like other
programs use.


> My main concern is the these "states" for aptitude are private data -
> excluding other software - and covering up why things are wrong.  (takeover
> issues)
>
> Lastly, an end user (me) can make install errors by using aptitude, dpkg,
> apt-get, dselect not realizing that aptitude uses privatized unshared
> current system disk status that isn't what dpkg uses (and how would you know
> if it's not in a status file to see?)
>

As above, most of pkgstates is actually private to aptitude.  Some of
it is duplicated for convenience, however, aptitude does take measures
to keep in sync. with dpkg/apt when it is started.  Admitedly, this
process fails quite often.

For example, removing a package with apt-get can lead to aptitude
trying to reinstall that package.  Note that aptitude is aware that
the package has been removed, it just mistakenly believes the user has
requested it be installed again.


> There's a way to get aptitude states maybe by relying on dump software.
>  Though relying on anyone keeping dumpers efficient and up to date simply
> isn't a great idea.
>

I don't think it would be useful for an other program to grok
pkgstates to determine if something is installed, etc.  Please use the
normal dpkg and apt means for that.

In theory, the only unique information in pkgstates is whether the
user has pending actions marked in aptitude.


Any problem in this situation is due entirely to aptitude's unique
requirements.  IMO the current dpkg and apt status files are quite
adequate for those systems.

Please be aware that it is my next priority to resolve the issues in this area.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137771#23


Regards


Reply to: