Goswin von Brederlow wrote:
> Dave Witbrodt <[email protected]> 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.
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! :-( )
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.
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.
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?
Thanks again for your efforts,
Dave W.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
