separate out tzdata port/package - FreeBSD

This is a discussion on separate out tzdata port/package - FreeBSD ; I haven't looked at the actual code and have not given any deep thought to this, so the following might be silly. Is it possible to separate java tz data into its own port/package? Maybe even shared by all/some JDKs. ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: separate out tzdata port/package

  1. separate out tzdata port/package


    I haven't looked at the actual code and have not given any deep thought
    to this, so the following might be silly.
    Is it possible to separate java tz data into its own port/package?
    Maybe even shared by all/some JDKs.
    I usually install java from ports and it seems like a waste to rebuild
    the whole jdk just to get an updated tz data.

    --
    Andriy Gapon
    _______________________________________________
    freebsd-java@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-java
    To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"


  2. Re: separate out tzdata port/package

    on 05/09/2008 16:28 Andriy Gapon said the following:
    > I haven't looked at the actual code and have not given any deep thought
    > to this, so the following might be silly.
    > Is it possible to separate java tz data into its own port/package?
    > Maybe even shared by all/some JDKs.
    > I usually install java from ports and it seems like a waste to rebuild
    > the whole jdk just to get an updated tz data.



    Sorry, still no code.
    But here's an idea how this suggested port/package would work.

    It would install (at least) tzupdater.jar somewhere in ${LOCALBASE}/lib
    or share.
    In its install script it would iterate over registered Sun Java VMs
    (javavms file) and execute $vm -jar tzupdater.jar -u (or something similar).
    jdk* ports would grow a dependency on this new port and would execute
    tzupdater.jar as part of their build/install pretty much as they do now.

    The only issue that I see is that checksum for some files in jdk/jre
    installations would not be updated when tz files are modified. But I
    don't think that this is a show-stopper.

    What do you think?
    Thanks!

    --
    Andriy Gapon
    _______________________________________________
    freebsd-java@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-java
    To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"


  3. Re: separate out tzdata port/package

    On Fri, Nov 07, 2008 at 02:31:54PM +0200, Andriy Gapon wrote:
    > on 05/09/2008 16:28 Andriy Gapon said the following:
    > > I haven't looked at the actual code and have not given any deep thought
    > > to this, so the following might be silly.
    > > Is it possible to separate java tz data into its own port/package?
    > > Maybe even shared by all/some JDKs.
    > > I usually install java from ports and it seems like a waste to rebuild
    > > the whole jdk just to get an updated tz data.

    >
    > Sorry, still no code.
    > But here's an idea how this suggested port/package would work.
    >
    > It would install (at least) tzupdater.jar somewhere in ${LOCALBASE}/lib
    > or share.
    > In its install script it would iterate over registered Sun Java VMs
    > (javavms file) and execute $vm -jar tzupdater.jar -u (or something similar).
    > jdk* ports would grow a dependency on this new port and would execute
    > tzupdater.jar as part of their build/install pretty much as they do now.
    >
    > The only issue that I see is that checksum for some files in jdk/jre
    > installations would not be updated when tz files are modified. But I
    > don't think that this is a show-stopper.
    >
    > What do you think?
    > Thanks!


    I would certainly like to be able to get away from updating a lot of ports
    when a new tzupdater comes out. However, breaking the packing list for
    already installed ports is a show stopper.

    A possible alternative is to not install zoneinfo files for any of the JDKs
    but instead create symlinks to a centrally created set of zoneinfo files
    created by the tzupdater port you're suggesting. Its not actually a
    problem that you don't have a JDK to run tzupdater with (hint: see the
    current diablo-jdk16 port and how it handles tzupdater). For extra credit
    you could use the zoneinfo files from the existing misc/zoneinfo port
    rather than waiting for Sun to release updated tzupdater releases.

    I haven't looked into this at all, so there might be some tricks I'm
    missing.

    --
    Greg Lewis Email : glewis@eyesbeyond.com
    Eyes Beyond Web : http://www.eyesbeyond.com
    Information Technology FreeBSD : glewis@FreeBSD.org
    _______________________________________________
    freebsd-java@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-java
    To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"


+ Reply to Thread