Dave Witbrodt <dawit...@sbcglobal.net> writes:
> Goswin von Brederlow wrote:
>> Dave Witbrodt <dawit...@sbcglobal.net> writes:
>>> I use Sid, and have been interested in the appearance of the new
>>> ia32-apt-get facility.
>>>
>>> I see that ia32-apt-get has its own configuration files in
>>>
>>> /etc/ia32-apt
>>>
>>> After reading /usr/share/doc/ia32-apt-get/README.Debian, I'm a bit
>>> confused on how this new system works
>>
>> Sorry, I forgot to update README.Debian when I uploaded version
>> 22. The NEWS file is right about dropping the diversions.
>
> OK, that helps clear up some confusion.
>
>
>>> 2) When the new packages were first installed, my understanding was
>>> that commands like 'aptitude' and 'apt-get' had been diverted, and
>>> running them would actually run the corresponding 'ia32-apt*' wrapper
>>> instead. Reading NEWS.Debian.gz in /usr/share/doc/ia32-apt-get now
>>> seems to indicate that the diversion scheme has been dropped.
>>>
>>> That raises many questions:
>>>
>>> Should users be using 'aptitude', or 'ia32-aptitude', or both?
>>
>> The later.
>
> OK, from now on I will stick with the 'ia32-*' scripts.
>
> They are wrapper scripts, right? It seems like the dependencies force
> 'aptitude' to be installed, but not 'apt' though.
Well, aptitude depends on apt so that gets pulled in too. But the next
upload will have a versioned depends on apt itself anyway.
>>> Should repository servers be listed in
>>>
>>> /etc/apt/sources.list
>>> and /etc/apt/sources.list.d/*.list
>>>
>>> or should they be in
>>>
>>> /etc/ia32-apt/sources.list
>>> and /etc/ia32-apt/sources.list.d/*.list?
>>
>> The later.
>
> OK, that's very helpful. The README.Debian file really needs to make
> that clear.
>
>
>>> 3) Do the 'ia32-apt*' wrappers keep their own database file for
>>> installed packages, or do they share the same database with the
>>> primary APT system. For example, I have noticed that 'aptitude' still
>>> correctly shows my automatic dependencies, but running 'ia32-aptitude'
>>> indicates that none of my installed packages are marked as automatic
>>> dependencies.
>>
>> The database for installed packages is kept by dpkg in
>> /var/lib/dpkg/status. That remains common for everything. But the
>> database of available packages is in /var/cache/ia32-apt/ and the
>> sources files are in /var/lib/ia32-apt/lists and will only bee used by
>> ia32-*.
>>
>> I don't use aptitude myself but it looks to me like
>> /var/lib/apt/extended_states contains informations about automatically
>> installed packages. With the wrappers
>> /var/lib/ia32-apt/extended_states is used instead. Does it help to
>> copy /var/lib/apt/extended_states to /var/lib/ia32-apt/extended_states?
>
> Yes. I copied both files,
>
> /var/lib/{ia32-,}apt/extended_states
>
> to a safe place, then overwrote the version in '/var/lib/ia32-apt'
> with the version from '/var/lib/apt'. You should consider providing a
> debconf question allowing the admin to copy this file (if desired) the
> first time installing the 'ia32-apt-get' package. Even if policy
> forbids this, you should mention the issue in README.Debian.
>
> Thank you for the reply. It was very helpful, and I now feel a lot
> better about using 'ia32-aptitude' exclusively.
>
> I'm still somewhat confused about the selection of packages available
> using 'ia32-apt*'. For example, I don't have 'wine' installed, but I
> see that there are packages called 'wine*' and 'ia32-wine*'. Is this
> merely because 'wine' is available in both 'amd64' and 'i386' versions
> in the repositories, and both packages are made available using the
> 'ia32-apt*' system? Is this the sort of thing meant to be solved by
> the new system -- since the 'i386' and 'amd64' packages are
> essentially the same thing?
Wine is somewhat a special case. Upstream already supports the win32
and win64 api. So there will be a 32bit and 64bit wine. I decided to
include wine in the rename.list (so it becomes ia32-wine) so that in
the future both i386 and amd64 wine packages can be installed in
parallel. That way users can run both 32bit and 64bit windows
applications. It also makes it easier to install the i386 wine now
while there still is a 32bit amd64 wine package.
But that might change again. It isn't clear yet how the 32/64 bit wine
support will be packaged. It might just have a single wine package
(i386 or amd64 wouldn't matter) that then uses both libwine and
ia32-libwine for the actual execution.
As for the new system I assume you refer to multiarch. In multiarch
you would use wine/i386 and wine/amd64 if you need to specifically
pick one or the other. But that would be rare. Usualy you would just
say wine and let apt pick the right one.
> Thanks again,
> Dave W.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
