Re: New Multi-Arch field, architectures conffile and syntax questions
Aurelien Jarno <aurelien@aurel32.net> writes:
> On Sun, Jun 22, 2008 at 06:18:35PM +0200, Goswin von Brederlow wrote:
>> Hi,
> Hi!
>
>> Given the recent renewed interest in multiarch I've been updating the
>> old dpkg multiarch patches. Along the way there are 3 general decisions
>> relevant to dpkg, apt and any other frontend that I would like to
>> finalize:
>>
>> 1) /etc/dpkg/architectures
>> ==========================
>>
>> There should be a conffile to specify the architectures (apart from
>> all and the primary architecture) the admin wants to use on the
>> system. The list should not and can not be hardcoded in dpkg as they
>> are not port but cpu or software dependent. For example newer ia64
>> cpus can not execute ia32 code. i386 needs a 64bit kernel to run
>> amd64. Powerpc needs qemu to run i386. And so on.
>>
>> In the patches I used /etc/dpkg/architectures as conffile. The file
>> can be missing, in which case only all and the primary architecture
>> (the one dpkg is compiled for) are allowed. The file contains one
>> architecture per line and lines starting with '#' or empty are
>> ignored.
>>
>> I think apt should also use /etc/dpkg/architectures and download
>> Packages files from all binary-* mentioned therein (besides the
>> primary architecture) unless that setting is overridden in apt.
>
> I personally fails to see why dpkg should know about this information.
>>From my point of view, this is something needed for apt, so that it can
> select which package to install when calling apt-get install. OTOH, dpkg
> only need to install packages it is asked to install.
>
> Given that, the best is probably to add a configuration variable in
> /etc/apt/apt.conf.
Dpkg already checks for the right architecture. I just extended
that. Removing the check is also an option.
>> 5) meta files / maintainer scripts (dpkg only)
>> ==============================================
>>
>> If multiple architectures of a package are to be installed we need
>> multiple .list, .postinst, ... files, one per architecture. The
>> current patches use 2 functions (and some convenience wrappers) to
>> generate the location of a meta file:
>>
>> void pkgadmindirbuf(struct varbuf *, struct pkginfo *);
>> void pkgadminfilenamebuf(struct varbuf *, struct pkginfo *);
>>
>> All access to INFODIR goes through those 2 functions so there is a
>> single place that decides on the name scheme. Currently the
>> following is used:
>>
>> dir = /var/lib/dpkg/info/
>> filename = libfoo.type for all and primary architecture
>> filename = libfoo.arch.type for other architectures
>>
>> Since '.' is allowed in package names I suggest using '_' as
>> sperarator at a minimum.
>
> I agree that the current implementation does not work for package with a
> dot in their name. If we switch to ':' to specify the architecture in
> an apt line, I suggest to also use it here.
Aren't there some filesystems that have problems with : in names? hint,
hint :)
>> A more involved change would be to use the following:
>>
>> dir = /var/lib/dpkg/info/package/
>> filename = arch.type
>>
>> Both replacing and removing of packages currently have to scan all of
>> INFODIR in search meta files belonging to the package in
>> question. With about 6k entries in INFODIR that causes a good amount
>> of readdir(), strrchr() and strcmp() calls that would be avoided.
>>
>> As for implementation I would create an /var/lib/dpkg/info/version
>> file containing 1 (old names) or 2 (new names). Upgrades could default
>> to format 1 and new installs could default to format 2. A simple
>> script could convert between 1 and 2 provided no multiarch packages
>> are installed. A case by case mode could also be done but I would
>> rather not.
>>
>
> I don't really like this solution involving a possibly problematic
> conversion. While having maintainer script whose name may or may not
> contain the architecture may looks confusing at a first glance, it's
> just a matter of time until all packages are rebuilt and use the new
> naming scheme.
Aeh. I think you misunderstand. The renaming will be done by dpkg. The
deb files will still have just "postinst" in control.tar.gz. The
naming is done when dpkg installs the maintainer scripts from the temp
directory into INFODIR.
The non native arch scripts have to be renamed and unless there is a
transition (either explicitly or on upgrade of each package) the names
for native packages won't change.
MfG
Goswin
Reply to: