[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#363482: Proposed fix for update-fonts-alias /etc/X11/fonts/X11R7 heirarchy



# well, this /wasn't/ a debhelper bug, but now it is...
reopen 364530
clone 364530 -1
submitter -1 !
reassign -1 debhelper 5.0.33
retitle -1 debhelper: should not promote the broken /etc/X11/fonts/X11R7 dir
tags 364530 patch
thanks

Attached is a first run at a patch for update-fonts-alias which eliminates
the need for the /etc/X11/fonts/X11R7 heirarchy.  An explanation of the
process:

- update-fonts-dir is still called, either with or without the
  --x11r7-layout option, and acts on a single directory.  When called
  without --x11r7-layout, it continues to act on the named subdirectory
  of /usr/X11R6/lib/X11/fonts for compatibility with existing packages; with
  the option, it acts on /usr/share/fonts/X11 as expected.  This updates the
  fonts.dir file for only the named directory, which should be the one the
  package installed its fonts to.
- update-fonts-alias is called with a subdirectory name and an optional
  --x11r7-layout option which is honored only for compatibility with font
  packages that have already updated to use it.  If --x11r7-layout is
  passed, u-f-a looks in both /etc/X11/fonts/$subdir and
  /etc/X11/fonts/X11R7/$subdir for alias files.  Otherwise, it looks *only*
  in /etc/X11/fonts/$subdir.  In both cases, the invocation will generate
  fonts.alias files in *both* /usr/share/fonts/X11/$subdir *and*
  /usr/X11R6/lib/X11/fonts/$subdir, whichever is present.  This is
  acceptable because fonts.aliases files only map aliases to font names,
  *not* to font files, so they can appear anywhere in the X FontPath without
  ill effect.  (Empirically verified prior to writing this patch.)
- update-fonts-scale something something.  I dunno, this probably parallels
  u-f-a, but I haven't tested it yet.

This means that /etc/X11/fonts/X11R7 should be immediately deprecated once
this patch is uploaded, in favor of the original /etc/X11/fonts.  The
dh_installxfonts handling that was changed in debhelper 5.0.33 should be
reverted; as well as, I guess, the previous path changes in 5.0.31.  It
should still pass --x11r7-layout when calling u-f-d, but not when calling
u-f-a.  (U-f-s still to be determined.)

With those changes, I believe the only adjustment maintainers of
debhelper-using xfonts packages will need to make is to install their fonts
to the correct new directory.  Any currently working xfonts packages in the
archive will continue to work.  Any debhelper-using packages currently
installing their alias and scale files to /etc/X11/fonts/X11R7 will break on
rebuild and will need to be fixed before the next upload.

Please test this patch and let me know if I've overlooked anything.  FWIW,
it checks out fine for me with the xfonts-thai-nectec package (the one that
spawned this bug), so 363482 should be closeable with no further
modifications of that package.

Off to poke at update-fonts-scale now. :)

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: