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

Re: latex-cjk upload to unstable ...



Danai SAE-HAN (韓達耐) <danai.sae-han@skynet.be> wrote:

> Thanks!  But I don't like removing the log files, even if the
> compilation successful, because there are a number of warnings that I
> like to keep for everyone to see.  E.g. some characters aren't
> included in the 55th page of the Big5 fonts (bkai and bsmi), and a
> warning is outputted.
>
> However, such an error trapping makes it swankier and more useful
> should something go wrong.  So I'll definitely include it.

Yes, it makes sense to keep the logfiles - just take out the rm command.

>> > Also, latex-cjk-chinese-arphic depends on the fonts
>> > ttf-arphic-{bkai00mp,bsmi00lp,gkai00mp,gbsn00lp}.  But there are also
>> > two new fonts by Arne Götje, ukai and uming, using Unicode and merging
>> > resp. bkai+gkai and bsmi+gbsn.  Both ukai and uming Debian packages
>> > provide the older ttf-arphic-* package names, so debuild doesn't
>> > recognize that only ukai and uming are installed, and not the original
>> > (older) packages.
>> 
>> Does that mean that the new packages claim to provide the old fonts, but
>> actually don't do this?  Or are they just in a different format?
>
> Arne Götje's ttf-arphic-ukai and ttf-arphic-uming packages provide
> each one TTF, ukai.ttf and uming.ttf resp.  So they can coexist with
> the original ttf-arphic-* files.
>
> In my case, I recently did a clean reinstall of Linux and only
> installed the ukai and uming packages.  I had hoped debuild would
> notice this, and give me a warning, but alas it didn't.

Hm, it seems to me as if ttf-arphic-ukai is wrong in declaring 

Provides: ttf-arphic-bsmi00lp, ttf-arphic-gbsn00lp

if it does not contain the same font files.  It might be a good
replacement from the point of view of a user, but it's not a replacement
in terms of package dependencies.  I think this relationship should
rather be in the description.  I suggest filing a bug.

>> >   How can I force a Build-Depends on the original TTF packages instead
>> > of the newer Unicode packages?  
>> 
>> It might be possible with versioned Build-Depends or alternatively with
>> Build-Conflicts.  However, it seems to me there's an underlying problem
>> that I don't understand yet.  Do the source packages for the "old" fonts
>> still exist?
>
> I have tried a versioned Build-Depends, but that doesn't work.
> The source packages of the "old" fonts still exist, and are in no way
> deprecated.  You can download them under the names
> ttf-arphic-bkai00mp, ttf-arphic-bsmi00lp, ttf-arphic-gbsn00lp and
> ttf-arphic-gkai00mp; they provide resp. the TTF bkai00mp.ttf,
> bsmi00lp.ttf, gbsn00lp.ttf and gkai00mp.ttf.

I think this is an other reason to believe ttf-arphic-ukai's Provides
are buggy.  According to the policy, Provides can either contain virtual
packages (7.4), or packages that are to be completely removed (7.5.2
Replacing whole packages, forcing their removal).  So this behavior is a
Policy violation.  Will you file the bug, or should I?

> Because the original Arphic font packages are still available,
> pbuilder will correctly choose them instead of Götje's packages.

Ah, I understand.  Generally speaking, it works because Provides: isn't
supposed to contain a real package and will never be considered if a
real package exists (and if it doesn't, a Build-depends must still
declare a real-package alternative first, like this:

Build-Depends: gs-gpl | gs

)

>> > 5.
>> > Currently, latex-cjk-chinese-arphic is being pbuild'ed, and everything
>> > seems okay.  I have added all the necessary dependencies (e.g.
>> > perl-base for latex-cjk-chinese-arphic).
>> 
>> This is doubly strange.  First of all, perl-base is in Section: base and
>> has priority: required, so it should always be installed.  Second, AFAIK
>> perl-base is only a minimal stripped-down Perl for use in maintainer
>> scripts of packages in base, and should usually not be used as a
>> (build-)dependency.  Anyway, in my pbuilder chroot:
>> 
>> # dpkg -l perl perl-base
>> Desired=Unknown/Install/Remove/Purge/Hold
>> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
>> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
>> ||/ Name                     Version                  Description
>> +++-========================-========================-================================================================
>> ii  perl                     5.8.8-6                  Larry Wall's Practical Extraction and Report Language
>> ii  perl-base                5.8.8-6                  The Pathologically Eclectic Rubbish Lister
>
> Well, I didn't put the perl-base dependency at first, but pbuilder
> failed after an hour when it had to run "perl clonevf.pl [...]".
> Then I set "perl-base (>=5.8.0)" in the Build-Dependss line and it
> worked.  o.O?

How did it fail?  

build-essential depends on dpkg-dev, which in turn depends on perl5,
perl-modules.  perl5 is a virtual package that's currently provided by
perl and perl-base; maybe also by other packages.  perl-modules, on the
other hand, depends on  perl (>= 5.8.8-1).  Consequently, your
additional Build-Depends line should not have any effect.  Could it be
that something else was amiss?

> Next time I do a pbuild, I'll remove perl-base again and see what
> happens then.  Perhaps an updated pbuilder will do wonders.

You should always run pbuilder update before trying a build.  I doesn't
cost much time (especially compared to building the font packages), but
saves much grieve.

> Hmmm, I get the feeling that this package will be very polished when
> it's released.  I like building cathedrals. ;D

If it's possible, we could try uploading the cjk source package without
the font packages.  Or will it be uninstallable/unusable?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: