[Debian-in-workers] Draft for ttf-indic-fonts restructuring

Vasudev Kamath kamathvasudev at gmail.com
Sat May 14 12:05:03 UTC 2011


On 14:39 Sat 14 May     , Mahesh T. Pai wrote:
> Vasudev Kamath said on Sat, May 14, 2011 at 01:24:53PM +0530,:
> 
>  > I have asked for the opinions for renaming of ttf-indic-fonts
>  > before on this list but with no reply (I got reply only from
>  > bubulle :)). So this time I'm proposing a draft plan for renaming /
>  > restructuring of ttf-indic-fonts.
> 
> It is not because nobody is interested. At least it was not so, in
> my case.

Thanks for the reply. 
> 
>  > pkg-fonts has a new policy (drafting in progress) for the font
>  > packages for Wheezy. In short following are the main points
> 
> See?? Is it right to change the names only because some change in
> policy is coming up?  What if the changes are not accepted?

It is accepted but there is still some fine tuning going on check this
thread which is latest from pkg-fonts-devel [1]

> 
> IIRC, there was some mention that the changes would not happen.

I never saw any such mentions on pkg-fonts-devel if you have a link
which can confirm this fact please share it.

> 
>  > 1. Fonts will be named as fonts-[foundry]-name, here foundry will
>  > be name of author or company maintaining the font. After a long
>  > discussion it was decided to make foundry as optional. so in short
>  > new fonts will have name in the format fonts-name
> 
> So, all lohit fonts will come under one package? 

Lohit provides fonts for most of the Indian Languages they provide
both source (sfd) and binary (ttf) so its better to have each language
as seperate fonts-lohith-<language> package, also fonts team encourages
building fonts from source since it helps in finding bugs in fontforge

>And each of ML fonts wil have a package of its own?

What I meant is fonts maintained by SMC

> 
> Rest is pure user POV; please tell me if others expect / experience
> things differently.
> 
> Right now, for me, I install ttf-malayalam-fonts and
> ttf-devanagari-fonts (for Indic), because I know that is all I will
> require; but when I do the install for others, I install the
> ttf-indic-fonts metapackage.
> 
> Installing ttf-<lang>-fonts package gives me all families (serif,
> sans-serif etc) of fonts in that language, without much hassle.

I agree current ttf-indic-fonts package should be replaced by
fonts-indic meta package and each individual ttf-<language>-fonts
should be replaced by fonts-<language> to maintain the user POV. Sorry
I forgot to mention about these points

> I recognise that with more DFSG-free fonts becoming available, we will
> have better freedom in repackaging them; but right now, I see no
> reason to.

Not clear on what you meant by above
> 
>  > 2. deprecating defoma. Its decided to remove all the dependencies on
>  > defoma (Debian font manager) in Wheezy.
> 
> What does that mean from the user POV?

Well it has nothing related to user POV. Its pure policy, pkg-fonts
will soon deprecate and remove defoma and If we don't remove that
dependency from our package it will break our packages. Never mind
about that since I've already handled this for current ttf-indic-fonts
and will be released soon.

> 
>  > Now coming to ttf-indic-fonts, its a meta package (multiple source
>  > in single? or whatever I don't know how to describe it properly its
> 
> A metapackage depends on other packages; by itself, that package
> contains nothing. .

But in the case of ttf-indic-fonts it contains sources of all the
other ttf-<language>-fonts.
Normally there will be multiple related sources/binaries and
single meta package which simply allows you install all those
sources/binaries by just installing a metapackage. Even though
ttf-indic-fonts allows you install all the Indian Language fonts its
internal organisation is complex. So this point was just a maintainer POV.

> 
>  > complex :)) and debian-in itself is the upstream!. But there are
>  > fonts in the package which do have a valid upstream and have
>  > periodic releases, and this is really painful for maintainer who
>  > needs to keep track of individual fonts version and periodically
>  > check for updates!  If you don't believe me check this file in
>  > wsvn[1]. I had to manually go to each font file to find its
>  > upstream and versions.
> 
> Isn't that a problem with (previous) packaging practise?

Yeah and we need to rectify at some point in time rather than moving
with same right?

> 
> All meta-packages will obviously have Debian as "upstream". For
> example, you are unlikely to find an application called
> "gnome-desktop-environment" on the GNOME project. (errr... unless they
> have incorporated the debian/ files upstream).

Ok let me clarify on what I meant, I agree for meta packages team will be
upstream but what is happening here is (bit maintainer related) we
follow native format i.e there is no upstream downloaded orig.tar.gz
instead we create it by ourselves.

To be more clear consider a software it has a tar ball provided by
upstream which acts as orig.tar.gz now consider one of the font
package say ttf-malayalam-fonts we have both lohit font and fonts
provided by SMC (2 upstream project into single package). In other
words we are mixing them together and debian-in becomes upstream for
ttf-malayalam-fonts

> 
> If ttf-foo-font has described Debian (or this list) as upstream, it is
> a packaging problem.
> 
> And yes, every time a new upstream release happens, the maintainer
> does have to include the newer release in the package, (else people
> like me will file bug reports asking for packaging the latest release
> ...)

Well if we have one package for each upstream fonts Debian has DEHS
(Debian External Health Status) which notifies on new releases and
makes life of maintainer easier and of course keeps BTS clean :) (bug
should be filed when maintainer doesn't release new version for long
time, at least that is what I think)

> 
>  > So here is my suggestion lets seperate out all the fonts with valid
>  > upstream into their own source packages. Below is the fonts which do
> 
> AFAICT, all fonts have valid upstream.

Let me clarify one thing on what I meant by
"proper upstream" There are fonts in ttf-indic-fonts for eg. Kedage
and Malige which was made GPL by IISC Bangalore but later on nobody
maintains it nor anything improved in them. So this upstream is
although upstream of font it abandoned them. Eg. for proper upstream
can be lohit by RedHat and few of Malayalam fonts by SMC which is
available for download from some web interface and there is regular
update and fixes to them

> 
>  > have valid upstream
>  > 1. All the Lohit fonts (maintained by RedHat)
>  > 2. All Malayalam fonts except lohit (maintained by SMC)
>  > 3. Akar Gujarathi fonts (maintained by Kartik?)
> 
> Curious, how do you propose to deal with lohit-malayalam?
> 
> 
>  > So here is the plan each individual lohit fonts for a language goes
>  > to its own package say fonts-lohit-language? Suggestions are welcome.
> 
> aaaaaarghhhhh!!!!!

I added lohit there because I said All ml fonts, lohit-malayalam will
go to fonts-lohith-malayalam. Sorry for the confusion I hope now its
clarified


> How about this:-
> 
> 1. A package for each font - means a separate package for language
>    from same source.
> 
> 2. A meta-package for each source/upstream, 
> 
> 3. A meta-package for each language.
> 
> 4. A grandmother emtapackage for ttf-indic-fonts which depends on all
>    metapackages in #3?

Yes this was the idea basically thanks for putting it here. I forgot
to mention it in first mail

> 
>  > About fonts maintained by SMC: I think we can either have a single
>  > package by name fonts-smc or do we need to package individual fonts
>  > separately and have fonts-smc as meta package? (SMC members please
>  > give your suggestions.)
> 
> It is a package deal. (pun unintended)
> 
> Treat SMC with same way you will deal with lohit.

Ok that is good :)

> 
> Disclaimer - I am not a member of SMC.

No issues all suggestions are welcome I asked "SMC members" because
they are the upstream for those fonts

> 
>  > Now remains the fonts without proper upstream how do we deal with
>  > them? I'm open for suggestions here.
> 
> Please mention - I am not very familiar with other languages.
> I suspect you mean one of "not maintained by upstream" or "upstream
> untreacable" or "upstream not willing to fix bugs"?

Yes that is what I meant

> (snip here)
> 
>  > pkg-ruby-extras team i.e having transitional packages which will
>  > depend on new packages and which can be slowly removed from debian
>  > archive later.
> 
> A more tricky question:-
> 
> If I install foo-font; how will the system deal with other fonts
> installed by ttf-blah-fonts?

That is a good question what these transitional packages are meant for
is not to break existing tools which depends on them, this is a valid
case in ruby team but I don't think any other package depends on
ttf-indic-fonts

Regarding what happens to fonts installed by ttf-indic-fonts: Well
even I never thought I need to check this and will answer it after
that :)


> 
> Still more tricky situation:-
> 
> I installed ttf-indic-fonts.
> 
> Now, I install foo-font. What happens to foo.ttf (apt and friends will
> complain about foo.ttf being in 2 packages). Things can get still more
> complicated if foo.ttf is put in different locations, both available
> to user in multiple versions. 
> 
> Supplementary question - does the new packaging policy entail location
> other thatn /usr/share/fonts/ ??

Location won't change only change in naming convention of font
packages

> 
> What about 
> 
> /usr/share/fonts/truetype/ttf-<lang>-font directories on older
> systems?
> 
> Hope you get the issue.

Yes I got the issue we may need to remove those directories as part of
transitional packages or may be some other alternative I need to check
this thanks for pointing this

> 
>  > Well this is my draft plan, lets start a discussion on this and once
>  > everything is finalised we can start working on new packages.
> 
> Of course, my opinion only.

Thanks for suggestions it put light on some points which I didn't
think of while writing draft :)

Cheers,
-- 
Vasudev Kamath
http://blog.copyninja.info
http://identi.ca/vasudev
vasudev at joindiaspora.com (Ostatus)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-in-workers/attachments/20110514/a3c721b4/attachment.pgp>


More information about the Debian-in-workers mailing list