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

Bug#870786: texlive-bin: Make source package bootstrappable



On Tue, Aug 8, 2017 at 2:50 AM, Norbert Preining <preining@logic.at> wrote:
> Hi Daniel,
>
>> speaking, I've found there are enough of these cycles that it's easier
>> for now just to build without tex4ht.jar.  It would be nice if there
>> were a stage1 or nojava build profile in the texlive-bin source
>> package that would do the same thing.
>
> Do you need a different package or a target in debian/rules?
> From the above paragraph I could read that a target in debian/rules
> suffice, but that sounds unrealistic.
>
> Are there any other problems than the tex4ht.jar? I would actually
> prefer to ship texlive-binaries without the need to rebuild the
> jar, but that is a requirement.
>
> If a debian/rules target is not enough, I only see the way to
> create an additional packages
>         texlive-binaries-java
> that only contains the .jar file (and maybe others in future).
>
> Another idea - but I am not sure whether this is possible - would be
> to move the jar file into texlive-plain-generic where all the other
> tex4ht files are. But that would interfere with the arch=all status
> of texlive-plain-generic I guess.
>
> Grateful for any ideas, proposals, advice!

It would be best to have a full build profile rather than a custom
target in debian/rules, e.g. key the Java stuff from

ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES)))
    javac ... -o tex4ht.jar
endif

; and update debian/control with:

Build-Depends: ..., default-jdk <!stage1>, ...

...

Package: texlive-binaries-java
Architecture: any
Build-Profiles: <!stage1>
...

Or, if it makes more sense for texlive-binaries-java to be
Architecture: all, in that case just moving default-jdk to
Build-Depends-Indep would be sufficient.

And yes, it would probably be best to split the conditional parts out
into a separate package, so that the profile build just drops packages
instead of modifying the binary contents of existing packages.
-- 
Daniel Schepler


Reply to: