[Pkg-ia32-libs-maintainers] Bug#539236: Bug#539236: ia32-apt-get: Warn user that cache of '*.deb' files is relocated

[Goswin von Brederlow]

Dave Witbrodt <dawitbro at sbcglobal.net> writes:

> Goswin von Brederlow wrote:
>> Dave Witbrodt <dawitbro at sbcglobal.net> writes:
>>
>>> Package: ia32-apt-get
>>> Version: 22
>>> Severity: wishlist
>>>
>>> I sometimes manually save known working copies of deb files from
>>>
>>>     /var/cache/apt/archives/
>>>
>>> when updating Sid.  Since switching to the 'ia32-apt-get' system, I
>>> became confused about missing deb files for packages that were
>>> recently installed.  Tonight, I finally discovered (by accident) that
>>> 'ia32-apt-get' no longer uses '/var/cache/apt/archives' at all, but is
>>> actually using '/var/cache/ia32-apt/archives'!  So I had huge number
>>> of packages that would have just been sitting in
>>> '/var/cache/apt/archives' wasting space, while all new packages
>>> were being cached elsewhere.
>>>
>>> It would have been nice to have been warned about this in
>>> 'README.Debian', on the man pages, etc.
>>
>> Do you think people would mind if ia32-apt-get puts its downloads in
>> /var/cache/apt/archives? The debs are unaltered so they are perfectly
>> useable by the normal apt/aptitude, at least those of the native
>> architecture.
>
> Heh, I was assuming the debs were being saved their in the first
> place. My own feelings are mixed:
>
>     1.  I am strongly in favor of handling packages from multiple
>     architectures using a system like 'ia32-apt-get', but at the moment
>     I find myself confused about where it does its business.  The main
>     APT packages have their directories, and 'ia32-apt-get' has its
>     directories,  except that '/etc/apt/apt.conf' is still used by
>     'ia32-apt-get', and the cache of downloaded debs has moved to
>     '/var/cache/ia32-apt' but we could move it back to '/var/cache/apt'
>     if users wanted to..., etc.  (Further comments about confusion
>     below.)
>
>     2.  I think no one would be bothered at all if 'ia32-apt-get' used
>     '/var/cache/apt/archives', and maybe most are assuming it still is
>     using it... like I was.  However, with 'ia32-apt-get' transforming
>     packages the way it does, it may not be a good idea to put them in
>     a place where standard APT tools could reach them.

The transformation is done during the unpack stage of dpkg. The files
in the cache are pristine. It realy is just a matter of preventing
race conditions if apt-get and ia32-apt-get try to access the cache
simultaneously.

> My confusion would be helped very much if the behavior of
> 'ia32-apt-get' was documented more thoroughly, but at the moment I
> think this is impossible because the system is still changing too
> rapidly.  This is not a complaint, but merely an observation.
> (Actually, I tried using 'reportbug' to send a "kudos" message last
> night, but the BTS rejected the message!  :-(  )

Bad bts, bad. :) Yes, it is still changing and my hope is that I get
it back so that a simple "apt-get" will work. This is waiting for a
patch to be added to apt so ia32-apt-get can integrate cleanly into
apt without the dpkg-divert that caused such an uproar. The apt team
seems OK with the patch so far so it is just a matter of time.

> Once the system has solidified more, it would be nice to see some of
> this documented.  The 'README.Debian' file would be OK, but my opinion
> is that you should keep this file as small as possible to make it
> easier for users to get a quick overview without having to read a huge
> anthology.  I would prefer to see a second file with explanations of
> low-level issues, with particular attention to how 'ia32-apt-get' does
> things differently than the standard APT behavior.

Full ACK.

> In short, I think there should either be a complete split between
> standard APT and the new system -- including config files, deb cache,
> etc. -- or there should be much better documentation about how
> 'ia32-apt-get' works the same as standard APT and how it works
> differently.

or ????

You missed the, I assume, "or it should be integrated and use all the
same paths". That is still my goal.

>> I will have to work out the locking so apt-get and ia32-apt-get can't
>> run in parallel but I think sharing the cache might be best all
>> around.
>
> Forgive me for saying this, but the thought keeps popping into my head
> that it would have been desirable for the behaviors 'ia32-apt-get' is
> trying to achieve to have been incorporated directly into the the
> standard APT packages (and related packages, like 'aptitude', if
> necessary.)  I find myself wishing this everytime I find myself typing
> 'aptitude' instead of 'ia32-aptitude', or 'apt-cache' instead of
> 'ia32-apt-cache'.
>
> The single- vs. multi-architecture behavior could be selected using
> debconf questions (and, as a result, could be reset easily with
> 'dpkg-reconfigure'); the config files would all be in a single
> location; the cache of debs would all be in a single location;
> updating from within interactive 'aptitude' would work; etc.
>
> Is this kind of synthesis a long-term goal, or is the vision for
> 'ia32-apt-get' that it should remain a separate system from standard
> APT tools permanently?

That was what I had in versions 19 to 21 with the help of
dpkg-divert. You can read the outcry that caused on debian-devel.

But it is still a goal. Just has to be cleaner and sneakier.

MfG
        Goswin