Gerhard Tonn wrote:
> > > A new keyword Package64 is supported in debian/control. It describes the
> > > package name of a given package on a 64 bit platform.
> > >
> > > A new keyword Substvarname is supported in debian/control. It describes
> > > the name of a substitution variable used elsewhere in the control file,
> > > e.g. to specify dependencies. Its value is the package name. If the
> > > keyword is missing the variable name is derived from the package name.
> >
> > This is a lot of additional complexity intorudced apparently to keep the
> > changes as small as you can. I don't think this is a good idea.
> >
>
> Right, my design point is reducing the complexity for the maintainer,
> especially avoiding redundancy.
Avoiding redundancy and reducing complexity are not always the same
thing. Indeed they are frequently opposing goals. You have introduced a
lot of complexity to remove a small amount of redundancy.
Arnd Bergmann wrote:
> > descriptions as their 32 bit brethren. I think that is a bad idea. All
> > available packages on any given arch should have unique descriptions,
> > that explain what they contain; for 64 bit lib packages that would
> > include a note that they're 64 bit.
> That makes sense. OTOH, that would mean adding the sentence 'This
> is the 64 bit version of the library' to every library package even for
> systems that don't have any 32 bit packages installed. Is the 'unique
> description' requirement part of the policy?
Not as such, but I have filed bugs on packages that use the same
description as other packages before, will do so again, and would
certianly rather not release any of my library packages (such as aalib)
with different varients having the same description. I could also argue
that policy in fact requires it, though the argument is relatively weak.
Gerhard Tonn wrote:
> If this is really an issue, we could also add this information to the
> existing information, e.g. "the package installs to /usr/lib64 on 64 bit
> platforms".
If you put that in the Description field that is used to build both the
lib and the lib64 variants of a package, then the non 64 bit compile
would have an incorrect description.
I suppose it could be added as yet another substvar, but that is just
piling on even more complexity, and it will necessarily be less
flexible.
Arnd Bergmann:
> Then what do you want to put in the Architecture: field? Should we have
> something like 'Architecture: anylib64' or do you have something different
> in mind?
That's indeed a problem, and you really need to make the architecture
field for the 32 bit version have something like !anylib64 in it. Hmm.
Then the best I can come up with is something like this:
Package: libfoo1
Package64: lib64foo1
Provides: libfoo1-$(architecture)
Architecture: any
Description: the foo library
The foo library for all your bar needs.
Description64: the 64 bit foo library
The foo library for all your 64 bit bar needs.
Package: libfoo-dev
Package64: lib64foo-dev
Architecture: any
Depends: libfoo1-$(architecture)
Conflicts: libfoo-dev
Description: the foo library development files
Development files for the foo library.
Description64: the 64 bit foo library development files
Development files for the 64 bit foo library.
Arnd Bergmann:
> > The ${aalib1} is gross. I'd prefer something like a dependency on
> > aalib1-${architecture}, which is provided with apprioriate substitutions
> > by the library packages.
>
> We hadn't thought of that. Agreed, that would be a lot better, it will even
> make it easy to build-depend on installing some package for the
> native architecture when it does not come from the same source.
> Note that since you cannot have versioned depends and provides for
> one package, it will have to be more like (ignoring the Package64
> question for now):
>
> Package: aalib1
> Provides: aalib1-${Arch}
>
> Package: aalib1-dev
> Depends: aalib1-${Arch}
> Conflicts: aalib1 (<< ${Source-Version}), lib64aalib1 (<< ${Source-Version})
Of course it would be even nicer if dpkg's dependency syntax were
extended to be able to include the architecture. You really end up
needing this as a natural consequence of making dpkg be able to install
packages of more than one architecture at a time. Something like:
Depends: aalib1 [${architecture}] (= ${Source-Version})
Arnd Bergmann:
> > Or -- here's an idea -- make dpkg remap the locatons of libraries from
> > specially flagged 64 bit packages at install time based on a config
> > file. If that were done right the same config file could allow for the
> > often-requested feature of /dev/nulling /usr/share/doc and other
> > directories. Something like:
> >
> > arch orig-directory map-to
> > x86-64 /usr/lib /usr/lib64
> > 386 /usr/share/doc # discard
>
> Note that an increasing number of packages already installs to
> debian/tmp/usr/lib64 or need to be configured for
> - --libdir="\${prefix}/${libname}", so doing it at install time only is no
> real option unless you want to move debian/tmp/usr/lib64 (and
> others) to debian/tmp/usr/lib at build time and back at install time...
Seems to me we would want dpkg to deal with this, it would just leave
files already in /usr/lib64 alone. It would need to check for file
conflicts introduced by the remapping, but then you'd want to check for
those anyway, in case someone set up this mapping:
any /usr/doc/ /usr/share/doc/
any /usr/man/ /usr/share/man/
It's my understanding that directory remapping (and discarding) is
already slated for dpkg 2.0. I don't know at what stage its design is,
but all that's needed I think is to add an architecture field to that
design, to make a given remapping only apply to packages from a given
architecture.
Doesn't this avoid the entire need for complicated substitutions in
debian/rules and debhelper files?
Gerhard Tonn:
> > Also, how _do_ you plan to deal with postinst scripts that have /usr/lib
> > in them, and with shlibs files?
>
> I am working on it. The basic idea is to use variables as well, and
> preprocess the files by debhelper.
I guess shlibs files won't really be a problem, they don't include paths
anyway.
What are some examples of ways that maintainer scripts for shared
libraries use /usr/lib that have to be changed for /usr/lib64? I think
that none of the snippets added by debhelper mention /usr/lib, and it
seems it would be fairly rare for maintainer scripts to do so.
--
see shy jo
Attachment:
pgpX3E_uK8nzk.pgp
Description: PGP signature