Hello! I recommend inclusion of this change so that it can make way into 2.5.
Regards, -- Ilya Kasnacheev 2018-04-19 9:03 GMT+03:00 Petr Ivanov <mr.wei...@gmail.com>: > There is not much time left for Apache Ignite 2.5 release, so let’s move > stage II of packaging architecture implementation (with additional split > scheme discussion) to 2.6 scope. > > Instead, I’d like to include DEB package to Apache Ignite 2.5 release. > Corresponding PR is already prepared [1]. > > Also, I’ll try to prepare modifications for release procedure scripts to > automate uploading packages to our new Bintray RPM and DEB repositories > before the code freeze. > > > [1] https://github.com/apache/ignite/pull/3869 <https://github.com/apache/ > ignite/pull/3869> > > > > > On 18 Apr 2018, at 14:44, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > wrote: > > > > Copying anything manually to anywhere /usr (excluding /usr/local) is an > > example of slackwarization that package users and creators try to avoid. > > > >> By linux file hierarchy convention, home dir should be in /usr/lib > > > > Citation needed! I bet you're interpreting it wrong, since I've listed a > > random dir in /var/lib, and: > > ~/w/incubator-ignite% sudo ls -al /var/lib/lightdm > > drwxr-x--- 6 lightdm lightdm 4096 авг 14 2017 . > > drwxr-xr-x 89 root root 4096 мар 10 22:37 .. > > drwxrwxr-x 4 lightdm lightdm 4096 июл 19 2017 .cache > > drwxr-xr-x 5 lightdm lightdm 4096 июл 19 2017 .config > > drwx------ 2 lightdm lightdm 4096 апр 11 18:25 .gconf > > drwxr-xr-x 3 lightdm lightdm 4096 июл 19 2017 .local > > -rw------- 1 lightdm lightdm 283 апр 11 18:25 .Xauthority > > > > ...it definitely looks like a home dir. Which goes with additional > benefit > > of being writable by end-user. > > > > -- > > Ilya Kasnacheev > > > > 2018-04-16 9:22 GMT+03:00 Petr Ivanov <mr.wei...@gmail.com>: > > > >> > >> > >>> On 15 Apr 2018, at 10:19, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > >> wrote: > >>> > >>> Hello! > >>> > >>> With existing binary archive, user can move directories from > >>> apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to > >> activate > >>> them. > >>> > >>> But with RPM, user should not contemplate moving directories from > >>> /usr/lib/apache-ignite/optional to /usr/lib/apache-ignite. > >> > >> I always thought of that option as COPYING optional libs, not MOVING. > >> > >> > >>> > >>> > >>> User lacks permissions for that operation and it would defeat the > purpose > >>> of having a RPM (imagine trying to upgrade Ignite RPM version with a > >> setup > >>> like that). "Turning distribution into Slackware" should not be an > >> offering. > >> > >> Can’t imagine use case where Apache Ignite software is installed by one > >> user, and run by another, without sudo/root permissions. > >> Yet, ignite user’s login shell is disabled indeed and without sudo/root > >> permissions optional libs cannot be copied. > >> Also — the symlinks is a good idea, but I’ve already thought of it and > I’m > >> planning addition of special utility for enabling / disabling optional > libs > >> (like a2enable/a2disable) in next development iteration. > >> > >> > >>> > >>> How it could work: Imagine we create /var/lib/ignite, use it as > >>> IGNITE_HOME, add symlinks from files in /usr/lib to /var/lib/ignite. > This > >>> way, we can add and remove symlinks to modules in optional/, and thus > >>> enable and disable them as user sees fit. > >> > >> By linux file hierarchy convention, home dir should be in /usr/lib. > >> /var/lib/ is currently used for working files (MySQL alike). > >> > >> > >>> > >>> This also answers the problem of "what's IGNITE_HOME for visor launched > >>> from /usr/bin” > >> > >> That is addressed in separate task and will be fixed with minor startup > >> script redesign with universal location-independent solution. > >> > >> > >>> > >>> But obviously this will require dedication and effort. > >> > >> No problems with efforts after final design is discussed an agreed. > >> > >> > >>> > >>> > >>> -- > >>> Ilya Kasnacheev > >>> > >>> 2018-04-14 8:03 GMT+03:00 Peter Ivanov <mr.wei...@gmail.com>: > >>> > >>>> Current packages design (after installation) does not differ from > binary > >>>> archive - everything works (except necessity to run service instead > >>>> ignite.sh) just the same way, including libs/optional. > >>>> > >>>> Also, there can be issues with system JDK version by default, but > every > >>>> problem will be in journalctl and/or /var/log, and package has strong > >>>> dependency on any implementation of JDK 1.8. > >>>> > >>>> > >>>> I am lacking enough feedback about Apache Ignite from packages from > real > >>>> users, don’t know real use cases so still "moving in the dark". > >>>> > >>>> > >>>> On Fri, 13 Apr 2018 at 22:18, Denis Magda <dma...@apache.org> wrote: > >>>> > >>>>> Ilya, > >>>>> > >>>>> Thanks for your inputs. The reason why we decided to split Ignite > into > >>>>> several packages mimics the reason why Java community introduced > >> modular > >>>>> subsystem for JDK. That's all about size. Ignite distribution is too > >> big, > >>>>> and we're trying to separate it into several components so that > people > >>>> can > >>>>> install only the features they need. > >>>>> > >>>>> The point of a package is to ship something into root file system > that > >>>> can > >>>>>> be used from root file system. If cpp files require compilation we > >>>> should > >>>>>> not ship them, or ship them to 'examples'. Ditto with benchmarks. If > >>>>>> there's no mechanism to add optional libs to Ignite classpath, we > >>>> should > >>>>>> not ship optional libs. Moreover, some of 'optional' modules such as > >>>> yarn > >>>>>> don't make sense here because they're not supposed to be used with > >>>>>> standalone Ignite. > >>>>> > >>>>> > >>>>> Agree that we need to ship the code that is ready to be run. As for > the > >>>>> classpath thing, if an optional package is installed into the root > >> (core) > >>>>> package directory, then its jars have to be added to "ignite/libs" > >>>> folder. > >>>>> After that, the one needs to restart a cluster node, nd it will add > the > >>>>> just installed optional libs to the classpath. *Petr*, does it work > >> this > >>>>> way or can be implemented this way to address Ilya's concerns? > >>>>> > >>>>> -- > >>>>> Denis > >>>>> > >>>>> On Fri, Apr 13, 2018 at 7:00 AM, Ilya Kasnacheev < > >>>>> ilya.kasnach...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> 2018-04-13 7:42 GMT+03:00 Peter Ivanov <mr.wei...@gmail.com>: > >>>>>> > >>>>>>> On Thu, 12 Apr 2018 at 20:04, Ilya Kasnacheev < > >>>>> ilya.kasnach...@gmail.com > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> Moreover I did not find a way to start service if default > installed > >>>>> JVM > >>>>>>> is > >>>>>>>> Java 7 :( I understand it's EOL, still this is something that hit > >>>> me. > >>>>>>> > >>>>>>> > >>>>>>> Apache Ignite >=2.4 does not support Java 7 - it is said in > >>>>>> documentation, > >>>>>>> DEVNOTES and even in startup scripts. > >>>>>>> > >>>>>>> I have Java 8 too, but I could not get service from package to > start > >>>>>> Ignite since there's nowhere to put JAVA_HOME (or JVM_ARGS for that > >>>>>> matter). Is it possible to specify it while running packaged Ignite? > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> apache-ignite-libs is a totally unexpected package name. > >>>>> apache-ignite > >>>>>>> core > >>>>>>>> doesn't depend on it. It doesn't enable anything out of the box. > >>>> The > >>>>>>>> package is huge. > >>>>>>> > >>>>>>> ‘apache-ignite-libs’ is an aggregation package (for now) for all > >>>>> optional > >>>>>>> libs we are delivering. Possibly later they will be split more > >>>> granular > >>>>>> or > >>>>>>> even package per lib (like php, perl, python, etc. do for their > >>>> libs). > >>>>>>> This package dependency on ‘apache-ignite-core’ may seem confusing > >>>>>> though, > >>>>>>> I will try to explain it in IEP at least for current iteration. > >>>>>>> > >>>>>> > >>>>>> Okay, but how do you add optional libs to be included into Ignite > >>>>> classpath > >>>>>> while being launched by service? Is it even possible? If it isn't, I > >>>>> think > >>>>>> it doesn't make sense to ship apache-ignite-libs at all. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Further naming may become clear when we’ll start initiative on > >>>>> including > >>>>>>> packages to popular Linux distributions and theirs community will > >>>> join > >>>>>>> naming discussions. > >>>>>>> > >>>>>> Renaming packages once they're deployed widely will be a pain point > to > >>>>> out > >>>>>> users. Some things should probably be thought out in advance. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Frankly speaking, I'm not sure that improvements over Stage I are > >>>>>> enough > >>>>>>> as > >>>>>>>> of now. For demo-like activity, we can probably go with one > package > >>>>>> fits > >>>>>>>> all. > >>>>>>>> > >>>>>>> > >>>>>>> The process of finding the best package architecture is iterative, > >>>> but > >>>>>>> previously community agreed in split design proposed for 2.5 > release. > >>>>>>> > >>>>>>> Also, split architecture is half of proposed improvements. The > other > >>>>>> half - > >>>>>>> new process for deploying packages to Bintray (with virtually > >>>>> indefinite > >>>>>>> storage capabilities). > >>>>>>> > >>>>>> I think we could drop the split for now, or at least drop > >>>>>> apache-ignite-libs package at all. Probably also drop > >> apache-ignite-cpp > >>>>>> package and maybe apache-ignite-benchmarks. > >>>>>> > >>>>>> The point of a package is to ship something into root file system > that > >>>>> can > >>>>>> be used from root file system. If cpp files require compilation we > >>>> should > >>>>>> not ship them, or ship them to 'examples'. Ditto with benchmarks. If > >>>>>> there's no mechanism to add optional libs to Ignite classpath, we > >>>> should > >>>>>> not ship optional libs. Moreover, some of 'optional' modules such as > >>>> yarn > >>>>>> don't make sense here because they're not supposed to be used with > >>>>>> standalone Ignite. > >>>>>> > >>>>>> IMO it is not right to try and shove every file from Ignite > >>>> distribution > >>>>>> into some package. We should only put in packages things that can be > >>>>> used. > >>>>>> If something can't be used without copying it to a different FS > >>>> location, > >>>>>> it should be in examples or not packaged at all. > >>>>>> > >>>>>> In my opinion, it doesn't make sense to implement an underwhelming > >>>>> package > >>>>>> split right now just because we have agreed to have *some* package > >>>> split > >>>>> in > >>>>>> 2.5. Let's aim for happiness. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Ilya Kasnacheev > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> > >>>>>>>> 2018-04-12 19:10 GMT+03:00 Petr Ivanov <mr.wei...@gmail.com>: > >>>>>>>> > >>>>>>>>> If someone from PMCы or Committers still sees necessity about > >>>>>> including > >>>>>>>>> these tasks into Apache Ignite 2.5 release, this is the last > >>>> chance > >>>>>> to > >>>>>>> do > >>>>>>>>> so. > >>>>>>>>> Otherwise this task will be moved to at 2.6 release at least, or > >>>>> even > >>>>>>>>> moved to backlog indefinitely. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On 9 Apr 2018, at 19:08, Petr Ivanov <mr.wei...@gmail.com> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> To top new RPM architecture off, update to release process is > >>>>>>>> introduced > >>>>>>>>> — [1] [2]. > >>>>>>>>>> > >>>>>>>>>> Both tasks (this one and IGNITE-7647) are ready for review and > >>>>>> should > >>>>>>>> be > >>>>>>>>> merged simultaneously. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-8172 > >>>>>>>>>> [2] https://github.com/apache/ignite-release/pull/1 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On 2 Apr 2018, at 18:22, Ilya Kasnacheev < > >>>>>> ilya.kasnach...@gmail.com > >>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hello! > >>>>>>>>>>> > >>>>>>>>>>> Let me share my idea of how this shoud work. Splitting package > >>>>>> into > >>>>>>>>>>> sub-packages should be dependency-driven. > >>>>>>>>>>> > >>>>>>>>>>> It means that all Ignite modules without dependencies or with > >>>>>> small > >>>>>>>>>>> dependencies (such as ignite-log4j) should be included in > >>>>>>> ignite-core. > >>>>>>>>> It > >>>>>>>>>>> doesn't make sense to make a zillion RPM packages. > >>>>>>>>>>> > >>>>>>>>>>> Critical things like ignite-spring and ignite-indexing should > >>>> be > >>>>>> in > >>>>>>>>>>> ignite-core of course, even if they have dependencies. > >>>>> Ignite-core > >>>>>>>>> should > >>>>>>>>>>> be fully self-sufficient and feature-complete. > >>>>>>>>>>> > >>>>>>>>>>> However, e.g. .net API should probably be in a separate > >>>> package, > >>>>>>>>> because it > >>>>>>>>>>> should depend on mono | net-core. We may also have > >>>> ignite-devel > >>>>>>>> package > >>>>>>>>>>> which should include all modules which only make sense for > >>>>>>> developers > >>>>>>>>> who > >>>>>>>>>>> write code. Such as hibernate integration. > >>>>>>>>>>> > >>>>>>>>>>> I'm not sure about MR modules. The main question should be, > >>>> does > >>>>>> it > >>>>>>>> have > >>>>>>>>>>> dependencies? Can it run stand-alone without writing code? > >>>>>>>>>>> > >>>>>>>>>>> Hope this helps, > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Ilya Kasnacheev > >>>>>>>>>>> > >>>>>>>>>>> 2018-03-27 15:10 GMT+03:00 Petr Ivanov <mr.wei...@gmail.com>: > >>>>>>>>>>> > >>>>>>>>>>>> Hi, Igniters! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Here are some news on our RPM packages initiative. > >>>>>>>>>>>> > >>>>>>>>>>>> 1. I’ve finished preliminary developing of Stage II version > >>>> of > >>>>>> RPM > >>>>>>>>>>>> packages [1]. Main “new feature” is — split design. Also I’ve > >>>>>> added > >>>>>>>>>>>> package.sh script for automating package building process > >>>> which > >>>>>>> will > >>>>>>>>> help > >>>>>>>>>>>> organise corresponding builds in TC as well as simplify > >>>> process > >>>>>> for > >>>>>>>>>>>> developers who wishes to have custom packages. > >>>>>>>>>>>> PR#3703 [2] is ready for review. Denis, in order to catch up > >>>>> with > >>>>>>>>> Apache > >>>>>>>>>>>> Ignite 2.5 release, I’d greatly appreciate your help in > >>>> finding > >>>>>>>>> reviewer. > >>>>>>>>>>>> 2. With the help of ASF INFRA team, we now have RPM [3] and > >>>> DEB > >>>>>> [4] > >>>>>>>>>>>> repositories on Apache Bintray. Though they are already > >>>>> prepared > >>>>>>> for > >>>>>>>>>>>> hosting RPM and DEB packages respectively, and there is a way > >>>>> of > >>>>>>>>> linking > >>>>>>>>>>>> them to apache.org/dist/ignite page, there is possible > >>>>>> alternative > >>>>>>>> in > >>>>>>>>>>>> storing there only plain directory layout corresponding to > >>>> each > >>>>>>>>> repository > >>>>>>>>>>>> type (RPM and DEB) and manage this layout (repodata, > >>>>>> distributions, > >>>>>>>>>>>> versions, etc.) by ourselves, having more control over > >>>>>> repositories > >>>>>>>> but > >>>>>>>>>>>> lacking some simplicity of deploying new releases. WDYT? > >>>> Should > >>>>>> we > >>>>>>>> try > >>>>>>>>>>>> Cassandra approach? They are storing their DEB packages as I > >>>>>>>> described > >>>>>>>>>>>> above [5]. > >>>>>>>>>>>> > >>>>>>>>>>>> Also — a question arose while I was working on this issue: > >>>>> which > >>>>>>> OSes > >>>>>>>>> (and > >>>>>>>>>>>> which versions of each) are we going to support (if we are > >>>>> going) > >>>>>>> in > >>>>>>>>> terms > >>>>>>>>>>>> of step-by-step list? Currently RPM packages are tested only > >>>>> with > >>>>>>>>> latest > >>>>>>>>>>>> CentOS (and, respectively — RHEL), but there are a lot more > >>>>>>> RPM-based > >>>>>>>>>>>> distributives [6] some of which are more o less popular among > >>>>> OS > >>>>>>>>> community > >>>>>>>>>>>> (ALT, Fedora, openSUSE, etc.). > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-7647 > >>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/3703 > >>>>>>>>>>>> [3] https://bintray.com/apache/ignite-rpm > >>>>>>>>>>>> [4] https://bintray.com/apache/ignite-deb > >>>>>>>>>>>> [5] https://bintray.com/apache/cassandra/debian#files/ > >>>>>>>>>>>> [6] https://en.wikipedia.org/wiki/Category:RPM-based_Linux_ > >>>>>>>>> distributions > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On 15 Mar 2018, at 22:15, Petr Ivanov <mr.wei...@gmail.com> > >>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> I suppose that most everything if not all from libs/options > >>>>> will > >>>>>>> go > >>>>>>>> to > >>>>>>>>>>>> OPTIONAL (I’d call it simply ‘apache-ignite-libs'). > >>>>>>>>>>>>> More precise lib selection (if something from optional would > >>>>>>> better > >>>>>>>> to > >>>>>>>>>>>> have in core package) will be discussed right after > >>>> preliminary > >>>>>>> split > >>>>>>>>>>>> architecture agreement. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 15 Mar 2018, at 22:11, Dmitry Pavlov < > >>>>> dpavlov....@gmail.com > >>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I like idea of keeping simple system of modules, so +1 from > >>>>> me. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Where optional libs (e.g Direct IO plugin) would be > >>>> included, > >>>>>>> would > >>>>>>>>> it > >>>>>>>>>>>> be > >>>>>>>>>>>>>> core or optional? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> чт, 15 мар. 2018 г. в 22:09, Denis Magda < > >>>> dma...@apache.org > >>>>>> : > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> How big would be a final core module? > >>>>>>>>>>>>>>>> Around 30M. Can be shrinked to ~15M if separate Visor and > >>>>>>> create > >>>>>>>>> it’s > >>>>>>>>>>>> own > >>>>>>>>>>>>>>>> package. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Guys, 30 vs 280M is a huuuuge difference. I would agree > >>>>> with > >>>>>>> Petr > >>>>>>>>> and > >>>>>>>>>>>>>>> propose the simplest modular system: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - core module that includes basic Ignite capabilities > >>>>>> including > >>>>>>>> SQL, > >>>>>>>>>>>>>>> compute grid, service grid, k/v > >>>>>>>>>>>>>>> - optional module hosts the rest - ML, streamers > >>>> integration > >>>>>>>> (kafka, > >>>>>>>>>>>>>>> flink), kubernetes, etc. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> Denis > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Thu, Mar 15, 2018 at 12:36 AM, Petr Ivanov < > >>>>>>>> mr.wei...@gmail.com> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> *DEB package > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 15 Mar 2018, at 10:35, Petr Ivanov < > >>>>> mr.wei...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Considering that DEV package for now is almost platform > >>>>>>>>> independent > >>>>>>>>>>>>>>> (its > >>>>>>>>>>>>>>>> a java application more or less), that package will work > >>>>>> almost > >>>>>>>> on > >>>>>>>>> any > >>>>>>>>>>>>>>>> DEB-based linux, including but not limited to Ubuntu, > >>>>> Debian, > >>>>>>>> etc. > >>>>>>>>>>>>>>>>> The only restriction is existence of systemctl (systemd) > >>>>>>> service > >>>>>>>>>>>>>>> manager > >>>>>>>>>>>>>>>> — we are dependent on it. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thats why, for instance, our RPM repository is called > >>>>> simply > >>>>>>>> ‘rpm’ > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>> package has no arch or dist suffix — it will work on > >>>>> CentOS, > >>>>>>>> RHEL, > >>>>>>>>>>>>>>> Fedora, > >>>>>>>>>>>>>>>> etc. with presence of aforementioned systemd. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 15 Mar 2018, at 07:57, Dmitriy Setrakyan < > >>>>>>>>> dsetrak...@apache.org> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Will Debian package work for Ubuntu? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> D. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Wed, Mar 14, 2018 at 9:52 PM, Petr Ivanov < > >>>>>>>>> mr.wei...@gmail.com> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Not a problem, rather nuisance. Also, when we will > >>>> move > >>>>> to > >>>>>>>>> official > >>>>>>>>>>>>>>>>>>> repositories, there can be a problem from OS > >>>> community. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Concerning DEB packages — I plan to use RPM as base > >>>> for > >>>>>> DEB > >>>>>>>>> package > >>>>>>>>>>>>>>>> build > >>>>>>>>>>>>>>>>>>> (package layout / install scripts) for speeding up > >>>>> things > >>>>>>> and > >>>>>>>>>>>>>>> excluding > >>>>>>>>>>>>>>>>>>> possible duplication and desynchronisation, so its a > >>>>>> matter > >>>>>>> of > >>>>>>>>> ’sit > >>>>>>>>>>>>>>>> and do’ > >>>>>>>>>>>>>>>>>>> rather then some technical research. Thats why I rose > >>>>>>>> discussion > >>>>>>>>>>>>>>> about > >>>>>>>>>>>>>>>>>>> future package architecture, so that after agreement > >>>> I'm > >>>>>> be > >>>>>>>>> able to > >>>>>>>>>>>>>>>> pack > >>>>>>>>>>>>>>>>>>> both RPM and DEB identically. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Yet, if you insist, I can create DEB package according > >>>>> to > >>>>>>>>> current > >>>>>>>>>>>> RPM > >>>>>>>>>>>>>>>>>>> layout in no time. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 15 Mar 2018, at 04:53, Dmitriy Setrakyan < > >>>>>>>>>>>> dsetrak...@apache.org> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Peter, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I don't think the package size of 280M is going to > >>>> be a > >>>>>>>>> problem at > >>>>>>>>>>>>>>>> all, > >>>>>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>> what you are suggesting can be an improvement down > >>>> the > >>>>>>> road. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> In the mean time, I think our top priority should be > >>>> to > >>>>>>>> provide > >>>>>>>>>>>>>>>> packages > >>>>>>>>>>>>>>>>>>>> for Debian and Ubuntu. Having only RPMs is not nearly > >>>>>>> enough. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Agree? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> D. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Wed, Mar 14, 2018 at 5:36 AM, vveider < > >>>>>>>> mr.wei...@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi, Igniters! > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Release 2.4 is almost there, at least binary part of > >>>>> it, > >>>>>>> so > >>>>>>>>> I'd > >>>>>>>>>>>>>>> like > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> move > >>>>>>>>>>>>>>>>>>>>> forward to further improve and widen AI delivery > >>>>> through > >>>>>>>>>>>> packages. > >>>>>>>>>>>>>>>>>>>>> As of now, Apache Ignite ships in RPM package > >>>> weighing > >>>>>>> about > >>>>>>>>>>>> 280M+ > >>>>>>>>>>>>>>>> and, > >>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> improve usability and significantly reduce required > >>>>>>> download > >>>>>>>>>>>>>>> sizes, I > >>>>>>>>>>>>>>>>>>>>> purpose that in 2.5 release we introduce splitted > >>>>>> delivery > >>>>>>>> as > >>>>>>>>>>>>>>>> follows: > >>>>>>>>>>>>>>>>>>>>> - CORE > >>>>>>>>>>>>>>>>>>>>> - bin > >>>>>>>>>>>>>>>>>>>>> - config > >>>>>>>>>>>>>>>>>>>>> - libs (!optional) > >>>>>>>>>>>>>>>>>>>>> - OPTIONAL LIBS > >>>>>>>>>>>>>>>>>>>>> - BENCHMARKS > >>>>>>>>>>>>>>>>>>>>> - DOCS (?) > >>>>>>>>>>>>>>>>>>>>> - EXAMPLES > >>>>>>>>>>>>>>>>>>>>> - .NET PLATFORM FILES > >>>>>>>>>>>>>>>>>>>>> - C++ PLATFORM FILES > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> This architecture, as I assume, will add flexibility > >>>>> (no > >>>>>>>>> reason > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> download > >>>>>>>>>>>>>>>>>>>>> all 280M+ of binaries where you are to run only core > >>>>>> node > >>>>>>>>>>>>>>>> functionality) > >>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>> maintainability (you are in full control of what is > >>>>>>>> installed > >>>>>>>>> on > >>>>>>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>>>> system). > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> After successful architecture choice, same scheme > >>>> are > >>>>>>>> planned > >>>>>>>>> to > >>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>> used in > >>>>>>>>>>>>>>>>>>>>> DEB packages as well. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> WDYT? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>> Sent from: > >>>>>>>> http://apache-ignite-developers.2346864.n4.nabble. > >>>>>>>>>>>> com/ > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
