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

Re: new lmodern package



Hi,

Norbert Preining <preining@logic.at> wrote:

> Good to hear that you are back!

Thanks.

> This I definitely do not udnerstand. The dh_clean does nothing more in
> our case than remove the debian/lmodern directory and the generated
> debhelper scripts, why should this force the use of Build-Depends.
>
> Maybe I don't understand the sentence above:
>   However many packages need Build-Dependencies for the clean target
>   (dh_clean), ...
> Does this mean: 
>   If you call dh_clean, you have to use Build-Depends
> I can't believe this, and also lintian complains about the
> Build-Depends.

That's it. Lintian is wrong if he complains. From the Debian policy:

,----
| The dependencies and conflicts they define must be satisfied (as
| defined earlier for binary packages) in order to invoke the targets in
| `debian/rules', as follows:[1]
|
| `Build-Depends', `Build-Conflicts'
|      The `Build-Depends' and `Build-Conflicts' fields must be
|      satisfied when any of the following targets is invoked: `build',
|      `clean', `binary', `binary-arch', `build-arch', `build-indep' and
|      `binary-indep'.
|
| `Build-Depends-Indep', `Build-Conflicts-Indep'
|      The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
|      be satisfied when any of the following targets is invoked:
|      `build', `build-indep', `binary' and `binary-indep'.
`----

When clean is run, Build-Depends-Indep is *not* guaranteed to be
satisfied. However, Build-Depends is.

> Ahh, good point, left over from when I first adapted the package and
> there was a stupid error in the 0.9 version of the debhelper scripts.,
> so I built my own 0.9.1 version.
>
> Yes, it should be >= 0.10

OK.

>>   3. What is the point of create-compat-links.sh if you don't install
>>      it? I assume it is not for future use by the Debian package
>>      since it touches /usr/local.
>
> Please see the discussion on the debian-tetex-main ML. We include it
> now only in the source package. For etch+1 we will remove the
> compatibility links, but install this script in doc for users
> convenience.

Ah, OK, thank you.

>>   4. I tend to disagree with some of the settings you chose for new
>>      fonts in lmodern.defoma-hints (for instance, the GeneralFamily set
>>      to Roman for typewriter fonts, but I didn't check everything---the
>>      defoma documentation says we can use our preferred value when
>>      the predefined values don't fit, therefore I had chosen values like
>>      Typewriter-SmallCaps).
>> 
>>      [ a while later... ]
>> 
>>      Ah, but I see from TODO.Debian that this is work in progress.
>
> Defnitely, I haven't checked the defoma stuff at all, the list is AFAIR
> automatically generated.

I am not sure I understand you correctly. debian/lmodern.defoma-hints
was *not* automatically generated in lmodern <= 0.92-11. However,
lmodern.scale and lmodern.fontlist-x11 are generated from
lmodern.defoma-hints.

Writing lmodern.defoma-hints was a rather tedious task involving running
t1disasm and gtkfontsel (IIRC) on every .pfb file and thinking about the
right parameters to set in the hint file.

> In fact I have *NO* experience with defoma etc, so if you or someone
> wants to improve this, you are welcome.

OK. Basically, what needs to be done is to go through all the .pfb files
and check the hints/add the missing ones. I'll have a look at it.

>>   5. Why do you use such stuff as 'if [ "X$newloc" = "X" ]'?
>>      AFAICT, this X thingie is useless nowadays.
>
> habit? bad habit? I don't know...

OK.

>>   6. In debian/rules, I see you are using dh_installtexfonts. OK.
>>      However, I seem to recall having read here that dh_installtex
>>      supersedes dh_installtexfonts. Am I mistaken?
>
> dh_installtex will be included in tex-common only on 0.16, so now I
> cannot use it.
>
> But yes, you are right, I want to switch to dh_installtex as soon as it
> is released with tex-common 0.16.

OK.

> Misunderstanding of Map vs MixedMap. 
>
> MixedMap only tells you that there are pk sources and type1 sources.
>
> Since we have
> 	dvipsPreferOutline true
> in updmap.cfg normally the type1 sources are used. Furthermore, the maps
> in these config files are *NOT* activated.
>
> If we would write Map instead of MixedMap, nobody would ever again be
> able to use the cmr pk fonts, even if he tells dvips that he does not
> wan to have type1 fonts!

But this happens only if the Map (currently MixedMap) lines in the
replacement .cfg files are uncommented by the user. If the user
uncomments the line with lm-rep-cmtext.map in 10lmodern-cm.cfg, it means
he wants LM used in place of CM, doesn't it? I'd say even when using PK
fonts, and even when dvipsPreferOutline is false. My reasoning is that
when uncommenting the line, the user means: "I want LM used whenever CM
should be used". Maybe you think he means instead "I want LM used
whenever CM-Type 1 should be used"?

> I think the only open problem is the Build-Depends stuff, I don't
> understand. If we stay with Build-Depend-Indep, I suggest we leave the
> pacakge as is, and for the next version I switch to dhinstalltex and the
> correct tex-common >= 0.16.
> (the >> 0.9 is correct anyway for now, say me as mathematician ;-))

OK, we can wait for tex-common 0.16.

> Any other urgend matters?

No.

> Florent, do you want to have write access to the lmodern svn repo, i.e
> pkg-texlive svn?

Yes, please. Thanks.

-- 
Florent



Reply to: