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

Re: New upload of the teTeX packages <Pine.NEB.4.33.0103251019580.23882-100000@tethys.fachschaften.tu-muenchen.de>



Hi,

>>>>> In 
 <[🔎] Pine.NEB.4.33.0103251019580.23882-100000@tethys.fachschaften.tu-muenchen.de> 
>>>>>	Adrian Bunk <bunk@fs.tum.de> wrote:
> On Sun, 25 Mar 2001, Masayuki Hatta wrote:

> > o Move to debhelper v3
> >
> > joeyh recommended this.

> There's one thing I hate in debhelper v3: You have to move the files for
> all packages (including the first one) out of debian/tmp and when you
> forget files they are in none of the packages.

Well, if you actually choose (I mean consciously) to keep using
debhelper v1 mode, that's alright.  I thought the package just became
obsolete and no one didn't follow the changes of debhelper...

> It would perhaps be more important if someone would work on using debconf.

Do we really need to use debconf?  For what?

> > o Patch-And-Tarball structure
> >
> > Like libc6 package, source package contains only pristine source
> > tarball and patches, not unpacked sources.  I mean:
> >
> > $ ls tetex-bin-1.0.7+20001218
> >
> > debian/
> > prep.sh
> > teTeX-src-beta-20001218.tar.gz
> > version
> >
> > and prep.sh(called from debian/rules) would take care of unpacking
> > tarball, applying patchs, etc.

> I do personally prefer to use the "normal" way of packaging because then
> you have your changes in the diff and you don't have to generate the diffs
> yourself. I think libc6 has much more patches than the tetex-* packages.

Okay.

> > I think, by this re-organization, updating package will be more easier
> > for maintainers.  Also this will make our changes in Debian package
> > more obvious.
> >
> > o Added Japanese support to xdvi and dvips
> >
> > I'll talk about it in a separate mail.

> My personal opinion is that such changes should go to upstream first since
> I don't like it when the programs in Debian behave other than the programs
> upstream makes 

I said "I'll talk to you later"...;-) anyway, of course I'll send the
patch to the upstream.  But as you know the tetex upstream is not as
active as once(seems they are pretty busy), so I thought it would be
nice to include this stuff in tetex-bin.deb for a while, like gs.  In
addition to that, this patch is not general solution - it's supposed
to be upper-compatible with the normal dvips, but not I18Ned,
basically just for DVIs generated by jtex/ptex(Japanese localized
TeX).  When Omega comes to usable(I don't know how long it takes,
though), it might be obsoleted, so I'm afraid it might not go into the
upstream.

> (and it makes it harder to send bugs upstream - you have to
> check if the bug exists in the original program, too) - but that's only my
> personal opinion.

BTW at this time I have no intension to merge the patch into the dvips
source itself.  What I thought was to make a directory texk/jdvipsk
and symlink everything from ../dvipsk except files to be modified,
copy such files, apply patches, and build a binary called jdvips(this
is the way odvips does).  So it should not bother anyone who uses the
normal dvips.

> > BTW it was too tough for me to divide tetex-bin, but I really think we
> > should do(it's too big!).  At least we should separate xdvi(depends on
> > X) and dvips(magicfilter etc. wants only this, a wishlist bug already
> > filed) from tetex-bin.

> There were ideas of a big reorganisation of the tetex-* packages. That's
> better than to split this or that program from one of the packages (but I
> think this should be done with several people working on it and it's
> something that is too late for woody).

Hmm.  If somebody is working on it, I gladly withdraw my proposal.

Best regards,
MH

--
Masayuki Hatta
University of Tokyo
g920202@mail.ecc.u-tokyo.ac.jp
mhatta@gnu.org / mhatta@debian.org / mhatta@opensource.gr.jp



Reply to: