Bug#225004: tetex-extra: Type1 fonts should be in a separate package
On 11.02.04 Florent Rougon (f.rougon@free.fr) wrote:
Hi all,
> > Well, I've read that passage, but I couldn't found anything about,
> > that I have to. Only what I have to do, if I want to.
>
> I guess you want obtain any good result without font.scale.
>
OK, so I have to. :-|
> > *grummel* I can't run unstable and I don't have Gnome 2 handy. If
> > anybody else is willing to add defoma support I'd appreciate it.
>
> With a sid chroot, you can:
> - launch X from the chroot (so, XFree 4.2 currently)
> - display X apps launched from the chroot on your regular woody X
> using TCP sockets (DISPLAY=localhost:0, and proper use of xauth);
> you should also firewall connections from the outside to the ports
> these sockets are listening on (6000 + DISPLAY_NUMBER).
>
drachi:[~] #ll /usr/src/debian-sarge-tetex.512
-r--r--r-- 1 root root 536870912 Feb 6 15:51 /usr/src/debian-sarge-tetex.512
drachi:[~] #mount -o loop /usr/src/debian-sarge-tetex.512 sarge/
drachi:[~] #chroot sarge/
drachi:/# cd
drachi:~# more /etc/debian_version
testing/unstable
drachi:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ubd0 507748 240334 256929 49% /
quite minimal.
yes I have a sarge chroot and I typed already apt-get update. But you
don't want to install Gnome2 and keep the system up to date over a
56k/48k modem connection, do you?
I should ask the next Debian mirror to give me a more recent snapshot
on DVD....
> > Do I have to include the Debian-changelog into tetex-extra-fonts?
>
> Yes, Debian packages must always have a Debian changelog.
>
OK.
> Note: If package A depends on B, policy allows you to have
> /usr/share/doc/A be a symlink to /usr/share/doc/B. Often, it is
> easier for the Debian maintainer _and_ the user (doesn't have to
> check every possible /usr/share/doc/directory). That is what I
> will do in the next lmodern version but I am still waiting for -8
> to reach the archive (*grummel* delayed because it has a new
> binary package...). In this case, you should probably link to
> /usr/share/doc/tetex-fonts if I remember the name correctly.
>
There are already links tetex-extra and tetex-doc to tetex-base. But
tetex-extra-fonts needs definitely an own doc dir and xfonts-tetex
will link to it.
> But really, I didn't make this up. This specific case is described in:
>
> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics
>
> (can also be found on Adobe's web site, of course...)
>
> > dh_installxfonts brings in a dependency on xutils (>= 4.0.3-xx)
> > as described in the policy. If this is not sufficient I'd rather
> > swap over that bug to debhelper and update the policy too.
>
> Sure, this would be better, if debhelper is updated quickly enough.
>
Question is: Is that really necessary, i.e. should we/I file a bug
against debhelper/the policy? Anybody so kind to ask that question
first on debian-devel?
> > don't look very critical, as the post{in,rm} script will look for
> > the existence of update-fonts-dir before trying to call it.
>
> Yes, I was just informing you on the opinion of the XFree86
> maintainer.
>
Well, I don't have to depend on the "latest" xutils just because of a
change in update-*. I would like to see a strong reason before tighten
the dependence.
> > 10.5. Symbolic links
> > --------------------
> >
> > In general, symbolic links within a top-level directory should
> > be relative, and symbolic links pointing from one top-level
> > directory into another should be absolute. (A top-level
> > directory is a sub-directory of the root directory /'.)
> >
> > For us the latter is the case. AFAICS.
>
> How so? /usr is a top-level directory and both the fonts and the
> symlink are under /usr. A Policy-compliant symlink in this case
> looks like:
>
top-level was misunderstood by me.
> > From you sed expression, I have the impression you are creating
> > absolute symlinks.
>
Correct.
> FYI, this is not to annoy people.
>
I guess the policy is not made for the for annoyance of maintainers. :-)
> If you understand this, you won't need to use dh_link and will save
> a lot of build time if you link many files (dh_link is written in
> Perl; and if you choose to list all the links on one command-line,
> there is the risk of overflowing it).
>
OK, will see, what I can do.
H.
--
sigmentation fault
Reply to: