Bugzilla – Full Text Bug Listing
| Summary: | Package DEB and RPM for Linux platform | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Xiaojun Ma <damage3025> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, david_williams, krzysztof.daniel, Lars.Vogel, mat.booth, matthias.mailaender, pwebster, thanh.ha |
| Version: | 4.4 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Xiaojun Ma
This seems a valid request ... volunteers welcome. Would p2 update and installation work if Eclipse is packaged as .deb or .rpm? I intend to revive https://build.opensuse.org/package/show/openSUSE:Dropped/eclipse but it seems to be a huge task. Getting the source code is not really easy. You don't offer source tarballs like http://monodevelop.com/Download does. Instead clicking source code redirects me to http://wiki.eclipse.org/Git which does not really answer the question where to grab the source to get started. Had a look at http://pkgs.fedoraproject.org/cgit/eclipse.git/tree/get-eclipse.sh and it seems it requires checking out a whole bunch of git submodules. Not sure if the open build server scm service module will be able to handle that. Simple Tarballs that include everything SHA checksums to verify it is trustworthy would help me out significantly here. It seems not even Gentoo builds Eclipse from source because "one does not simply compile Eclipse" (via IRC) and repackaging the binary builds is less effort. (In reply to Matthias Mailänder from comment #3) > I intend to revive > https://build.opensuse.org/package/show/openSUSE:Dropped/eclipse but it > seems to be a huge task. Getting the source code is not really easy. You > don't offer source tarballs like http://monodevelop.com/Download does. > Instead clicking source code redirects me to http://wiki.eclipse.org/Git > which does not really answer the question where to grab the source to get > started. Had a look at > http://pkgs.fedoraproject.org/cgit/eclipse.git/tree/get-eclipse.sh and it > seems it requires checking out a whole bunch of git submodules. Not sure if > the open build server scm service module will be able to handle that. Simple > Tarballs that include everything SHA checksums to verify it is trustworthy > would help me out significantly here. It seems not even Gentoo builds > Eclipse from source because "one does not simply compile Eclipse" (via IRC) > and repackaging the binary builds is less effort. See http://wiki.eclipse.org/Platform-releng/Platform_Build for how we (currently) build Eclipse, using Maven/Tycho. Normally, the native code (swt and launchers) is "pre-compiled" and the Maven/Tycho build simply "packages" those executable modules. That's probably not what you want, exactly, but there are some hints (in those instructions or various bugzilla entries) on how to compile the native code. Sorry, but "we" don't have the people/bandwidth to produce source tar balls, but if you (or someone else) figures out a way to do it (say, based on "tag" of "aggregator" project (or other projects)) I'm sure others would want to know/share/contribute. As for the p2 question in comment 2 ... I'm sure p2 would work "once installed", but but if asking it it would/could work as part of the RPM/DEB "post install" operations themselves, I do not know (but, would guess 'yes' ... but I know little about RPM/Deb details). This bug is much more complicated than it looks like. Building RPM/DEB *outside* of Linux distribution infrastructure, directly from binaries, is relatively easy, but the true source of problems is conflict with the potentially packaged version. Very often it is not possible to *replace* distro Eclipse with a foundation one - because distro Eclipse can be a dependency to other apps (f.e. distro RCP apps), and maintaining two or more packages providing the same software is a distro-specific nightmare (conflicts in bin, which one should be launched by default, which one should be integrated into system menu, etc. etc.). As of P2, it should work. The only troublesome use case is updating Eclipse itself (installing newer RPM, but I think it was fixed for Kepler). Now, In reply to Matthias Mailänder from comment #3 > I intend to revive > https://build.opensuse.org/package/show/openSUSE:Dropped/eclipse but it > seems to be a huge task. Getting the source code is not really easy. The real problem is that if you want to revive a distro Eclipse package, you need to build Eclipse according to distro rules - f.e. with software that is already a part of the distro. Please check if suse has maven stack :). > Had a look at > http://pkgs.fedoraproject.org/cgit/eclipse.git/tree/get-eclipse.sh and it > seems it requires checking out a whole bunch of git submodules. Not sure if > the open build server scm service module will be able to handle that. Yes it does. The source is checkout out only once and then made a part of source RPM. I'm sure other distros have similar mechanisms. > It seems not even Gentoo builds > Eclipse from source because "one does not simply compile Eclipse" (via IRC) Fedora does. So does Mageia. Adnan Hodzic (https://twitter.com/AbsintheSyringe) intended to update Eclipse for Debian. > and repackaging the binary builds is less effort. discussed that earlier. (In reply to Krzysztof Daniel from comment #5) > This bug is much more complicated than it looks like. Building RPM/DEB > *outside* of Linux distribution infrastructure, directly from binaries, is > relatively easy, but the true source of problems is conflict with the > potentially packaged version. > > Very often it is not possible to *replace* distro Eclipse with a foundation > one - because distro Eclipse can be a dependency to other apps (f.e. distro > RCP apps), and maintaining two or more packages providing the same software > is a distro-specific nightmare (conflicts in bin, which one should be > launched by default, which one should be integrated into system menu, etc. > etc.). > > As of P2, it should work. The only troublesome use case is updating Eclipse > itself (installing newer RPM, but I think it was fixed for Kepler). > > Now, In reply to Matthias Mailänder from comment #3 > > I intend to revive > > https://build.opensuse.org/package/show/openSUSE:Dropped/eclipse but it > > seems to be a huge task. Getting the source code is not really easy. > The real problem is that if you want to revive a distro Eclipse package, you > need to build Eclipse according to distro rules - f.e. with software that is > already a part of the distro. Please check if suse has maven stack :). > > > Had a look at > > http://pkgs.fedoraproject.org/cgit/eclipse.git/tree/get-eclipse.sh and it > > seems it requires checking out a whole bunch of git submodules. Not sure if > > the open build server scm service module will be able to handle that. > Yes it does. The source is checkout out only once and then made a part of > source RPM. I'm sure other distros have similar mechanisms. Even if build systems supports that getting a tarball (good enough for building with all sources and etc) as part of the official build results should be the first step if we want to play good with distros. > > > It seems not even Gentoo builds > > Eclipse from source because "one does not simply compile Eclipse" (via IRC) > Fedora does. So does Mageia. Adnan Hodzic > (https://twitter.com/AbsintheSyringe) intended to update Eclipse for Debian. > > > and repackaging the binary builds is less effort. > discussed that earlier. Just found http://download.eclipse.org/technology/linuxtools/eclipse-build/ with latest source tarball being version 4.2 via http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build Flatpak is the path forward for cross distro properly integrated. POC available at http://eclipse.matbooth.co.uk/flatpak/ . Close this one as wontfix. |