Bug#197154: Subject: It will be more convenient if xutils.postinst setups the font directories
Anton Zinoviev
Severity: wishlist
Now all font packages depend on xutils and invoke
update-fonts-{dirs,alias,scale} by themselves. Thats why packages
providing Type1 fonts (as gsfonts and scalable-cyrfonts) have to be
doubled -- one version for defoma and another for X. If xutils cares
to setup the font directories properly there will be no need to double
these font packages. There can be only one version which depends on
defoma and invokes update-fonts-* _only if_ these commands are
installed. In that case if xutils gets installed latter it cares to
setup the font directories.
I decided to split scalable-cyrfonts as type1-cyrillic, type1-teams
and type1-oldslavic. For now these packages depend on xutils but it
would be nice if I could remove this dependency.
Anton Zinoviev
--
To UNSUBSCRIBE, email to debian-x...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Branden Robinson
tag 197154 + moreinfo
thanks
On Thu, Jun 12, 2003 at 06:31:32PM +0300, Anton Zinoviev wrote:
> Now all font packages depend on xutils and invoke
> update-fonts-{dirs,alias,scale} by themselves.
Yes.
> Thats why packages providing Type1 fonts (as gsfonts and
> scalable-cyrfonts) have to be doubled -- one version for defoma and
> another for X.
I do not understand why this is so. Your conclusion seems hasty, and
does not follow from the sole identified premise.
> If xutils cares to setup the font directories properly there will be
> no need to double these font packages. There can be only one version
> which depends on defoma and invokes update-fonts-* _only if_ these
> commands are installed. In that case if xutils gets installed latter
> it cares to setup the font directories.
In general, a package in Debian is expected to do everything necessary
in its maintainer scripts to ensure that it is usable as intended once
it is marked "configured".
Your proposal would undermine that. Font packages could be installed
but not usable, or all font packages would have to Pre-Depend on xutils.
Actually, that wouldn't do it, either. A "trigger" mechanism to tell
xutils to run its postinst script again would be necessary.
> I decided to split scalable-cyrfonts as type1-cyrillic, type1-teams
> and type1-oldslavic. For now these packages depend on xutils but it
> would be nice if I could remove this dependency.
Unless you can provide me with a more persuasive case I'm going to
reject this request. Packages need to ensure that they get themselves
into a usable, configured state. They can't count on some other
package's postinst script to do it for them.
Also, I do not see why you consider removing a dependency on xutils to
be so important.
--
G. Branden Robinson | People are equally horrified at
Debian GNU/Linux | hearing the Christian religion
bra...@debian.org | doubted, and at seeing it
http://people.debian.org/~branden/ | practiced. -- Samuel Butler
Anton Zinoviev
>
> On Thu, Jun 12, 2003 at 06:31:32PM +0300, Anton Zinoviev wrote:
> > Thats why packages providing Type1 fonts (as gsfonts and
> > scalable-cyrfonts) have to be doubled -- one version for defoma and
> > another for X.
>
> I do not understand why this is so. Your conclusion seems hasty, and
> does not follow from the sole identified premise.
>
> > If xutils cares to setup the font directories properly there will be
> > no need to double these font packages. There can be only one version
> > which depends on defoma and invokes update-fonts-* _only if_ these
> > commands are installed. In that case if xutils gets installed latter
> > it cares to setup the font directories.
>
> In general, a package in Debian is expected to do everything necessary
> in its maintainer scripts to ensure that it is usable as intended once
> it is marked "configured".
Type1 fonts can be usable without X. One example is a print server
which uses ghostscript. Defoma provides ghostscript with fonts.
Another example can be TeX. The font packages only provide fonts and
they should not depend on particular font consumers. If some software
wants to use fonts it has to get them from Defoma (as ghostscript) or
directly (as X and fontconfig). Otherwise the font packages would
have to depend on all font consumers that don't support Defoma.
> Your proposal would undermine that. Font packages could be installed
> but not usable,
They are usable by all software that wants to use them.
> or all font packages would have to Pre-Depend on xutils. Actually,
> that wouldn't do it, either. A "trigger" mechanism to tell xutils
> to run its postinst script again would be necessary.
I am not sure I understand well this. But I see that I haven't
explained well something. Consider the following case -- the package
gsfonts is installed first, then comes xutils and lastly t1-teams. We
have the following scenario:
1. The postinst of gsfonts sees that there is no update-fonts-dir and
does nothing.
2. The postinst of xutils configures the font directories for packages
that are installed before it (gsfonts in our case).
3. The package t1-teams adds new fonts. Its postinst sees that there
are update-fonts-* scripts already and reconfigures the Type1 font
directory.
> Packages need to ensure that they get themselves into a usable,
> configured state. They can't count on some other package's postinst
> script to do it for them.
For a font package to be in a usable, configured state, one thing is
enough: its postinst to register the fonts with Defoma. For Type1
fonts we need more -- to configure the X font directories, but X is
able to afford this only because it is so important.
> Also, I do not see why you consider removing a dependency on xutils
> to be so important.
It is not important, it is only desirable. xbase-clients (with their
xftcache) and fontconfig are not much different to xutils with respect
to the font packages. Hopefully the maintainer of fontconfig is
willing to add support for Defoma, so there will be no need to depend
on fontconfig also.
It is also possible to add in xutils (or in some other X package) a
support for Defoma, but what I propose is a simpler solution.
Branden Robinson
> Type1 fonts can be usable without X. One example is a print server
> which uses ghostscript. Defoma provides ghostscript with fonts.
> Another example can be TeX. The font packages only provide fonts and
> they should not depend on particular font consumers. If some software
> wants to use fonts it has to get them from Defoma (as ghostscript) or
> directly (as X and fontconfig). Otherwise the font packages would
> have to depend on all font consumers that don't support Defoma.
I think Type1 font packages should assume they're going to be used both
for printing and by X clients, but should not fail to configure if the
commands that "register" them with the relevant pieces of infrastructure
are not available.
> > Your proposal would undermine that. Font packages could be installed
> > but not usable,
>
> They are usable by all software that wants to use them.
Only if the software knows where they are, and appropriate
files/registries have been updated.
> For a font package to be in a usable, configured state, one thing is
> enough: its postinst to register the fonts with Defoma.
I am unhappy with defoma. Hopefully its new maintainer will work with
me / persuade me to see whatever light I'm supposed to be seeing.
> It is not important, it is only desirable. xbase-clients (with their
> xftcache) and fontconfig are not much different to xutils with respect
> to the font packages. Hopefully the maintainer of fontconfig is
> willing to add support for Defoma, so there will be no need to depend
> on fontconfig also.
>
> It is also possible to add in xutils (or in some other X package) a
> support for Defoma, but what I propose is a simpler solution.
Well, xbase-clients is about to get busted into a bunch of pieces, and
in 4.3.0 probably will not even ship xftcache. xutils will probably
continue to ship utilities that manage X font directories, though.
Juliusz Chroboczek has done some work on X's font-cataloging tools
recently in the X Strike Force Subversion repository.
--
G. Branden Robinson | It just seems to me that you are
Debian GNU/Linux | willfully entering an arse-kicking
bra...@debian.org | contest with a monstrous entity
http://people.debian.org/~branden/ | that has sixteen legs and no arse.
Anton Zinoviev
>
> I am unhappy with defoma.
Me too. I discovered that I am not able to remove some fonts from my
packages. This is a design flaw, though it can be fixed.
But I am not very embarassed about Defoma because I feel that I if
some problem of Defoma starts to bother me too much, I will be forced
not to be lazy and fix it. :)
> Hopefully its new maintainer will work with me / persuade me to see
> whatever light I'm supposed to be seeing.
Defoma tries to be universal and possibly this is what makes it so
complex. It can generate authomaticaly fonts.scale and fonts.alias
for X, declare fonts and PS-name aliases for Ghostscript. I even
managed to create a package defoma-tex that is able to make Type1
fonts available for TeX. (But then I realised that no one will use it
-- gsfonts are internaly supported by TeX, for my packages I decided
to use a different way and xfonts-scalable doesn't support Defoma.)