Hi Shirish, shirish शिरीष 於 2019/2/15 上午2:41 寫道: > At bottom :- > > On 14/02/2019, Franklin Weng <franklin@goodhorse.idv.tw> wrote: >> Andreas Tille <tille@debian.org> 於 2019年2月15日 週五 00:07寫道： >> Hi Franklin, >> >>>> Rewriting the PhET package hasn't started yet. I'm considering to ask >>>> if >>>> University of Colorado would like to have such packages or not. At >>>> least >>>> I'll get newest offline version as they have completed many new HTML5 >>>> simulations recently. >>> Whatever you do about PhET - it should definitely not be part of the >>> ezgo source package but rather a separate package. >>> >> Originally ezgo-phet is a empty package to download a zip file in the >> postinst script. But the download ftp site was not stable. >> >> So I'm considering to make another deb package for different languages >> offline version and see if it can be published from USC _OR_ from my own >> ezgo repository, which is mirroring to some other places everyday. Then >> the ezgo-phet in blends is still a meta package. >> >> >> Franklin > Hi all, > > Please CC me as I'm not subscribed to the list. > > @Franklin - While I'm not sure whether you know the reason debian > dislikes large tarballs or everything in one repo. kinda scenario. As > a debian user I can share from just a user POV why it makes sense to > have anything in small sections. > > A similar example I could give is 0ad [1] . If you look at the 0ad > package today in debian you would see it is split into various > sub-parts as can be seen below - > > $ aptitude show 0ad > Package: 0ad > Version: 0.0.23.1-2 > State: installed > Automatically installed: no > Priority: optional > Section: games > Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org> > Architecture: amd64 > Uncompressed Size: 20.3 M > Depends: 0ad-data (>= 0.0.23.1), 0ad-data (<= 0.0.23.1-2), > 0ad-data-common (>= 0.0.23.1), 0ad-data-common (<=0.0.23.1-2), > libboost-filesystem1.67.0, libboost-system1.67.0, libc6 (>= 2.27), > libcurl3-gnutls (>= 7.16.2), libenet7, libgcc1 (>= 1:3.4), libgl1, > libgloox17, libicu63 (>= 63.1-1~), libminiupnpc17 (>= 1.9.20140610), > libnspr4 (>= 2:4.9.2), libnvtt2, libopenal1 (>= 1.14), libpng16-16 (>= > 1.6.2-1), libsdl2-2.0-0 (>= 2.0.8), libsodium23 (>= 1.0.14), > libstdc++6 (>= 5.2), libvorbisfile3 (>= 1.1.2), libwxbase3.0-0v5 (>= > 3.0.4+dfsg), libwxgtk3.0-0v5 (>= 3.0.4+dfsg), libx11-6, libxcursor1 (> > 1.1.2), libxml2 (>= 2.9.0), zlib1g (>= 1:1.2.0) > PreDepends: dpkg (>= 1.15.6~) > Description: Real-time strategy game of ancient warfare > 0 A.D. (pronounced "zero ey-dee") is a free, open-source, > cross-platform real-time strategy (RTS) game of ancient warfare. In > short, it is a historically-based war/economy game that allows players > to relive or rewrite the history of Western civilizations, focusing on > the years between 500 B.C. and 500 A.D. The project is highly > ambitious, involving state-of-the-art 3D graphics, detailed artwork, > sound, and a flexible and powerful custom-built game engine. > Homepage: http://play0ad.com/ > > a. So the first thing is many people in today's environments use > metered connections. Me and some of the people to whom I provide the > service have some sort of metered connections. In such a scenario, it > is much more easier to install few packages and over time update and > install the whole package without dedicated network bandwidth. > > b. One of the probably most under-appreciated but probably one of the > more widely used tool is debdelta. I have written about it in 2011 [2] > . If you have packages which are split it would be easier to use > debdelta on them rather than on the whole. > > c. Re-using libraries - This is best explained in Raphael's book > chapter 5 [3] . It makes sense to have shared libraries and split > packages so its easier to maintain. Bug-reporting, bug-triaging and > maintainance in both short, medium and long-term would bd easier. I > hope I was able to shed some light. It is possible that you may > already have known this, if so please excuse for the noise. Thanks for your explanation. Just that I guess PhET Offline is a special case -- it is not a (compiled) software, but is composed by many, many different simulations and html pages. The simulations used to be generated by Java applets and Flash, and currently they are writing them into HTML5, so that users (kids) don't need to install java or flash plugin anymore, and play on the mobile devices too. Since ezgo8 we have kept providing PhET Offline version in our system, in order to let kids and students who have no network connections play without problems. (Almost all the system and applications follow this rule too -- as long as they have a pre-installed system _OR_ a live DVD/USB, they don't need internet to use and learn everything from ezgo.) So here is the problem -- PhET is not (currently) something which can be easily split into different components. It is not a binary which use many shared libraries and can be cleaned in the package. When I ask for offline version (for zh_TW, which is not provided by default but needs to specially generate by PhET team) what I get is a whole big .bin file, which would extract the whole PhET and put an icon on the desktop. At least -- I won't put the whole compressed file in the ezgo source. But for Debian users who would like to install through ezgo repository they still need to download the whole compressed packages, which will be provided by me instead of the PhET team. -- Franklin Weng President, Board of Director, Software Liberty Association Taiwan Member, KDE e.V. LibreOffice Migration Professional Member, Board of Director, The Document Foundation Member, Free Software Foundation Europe
Attachment:
signature.asc
Description: OpenPGP digital signature