Bugzilla – Full Text Bug Listing
| Summary: | [eclipse-build] Create file lists of what should go into eclipse-{swt,rcp,platform,sdk} | ||
|---|---|---|---|
| Product: | [Tools] Linux Tools | Reporter: | Andrew Overholt <overholt> |
| Component: | eclipse-build | Assignee: | Packaging Tools Inbox <linux.packagingtools-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bdrung, niels, robert.munteanu |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | 1.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Andrew Overholt
I'm not really sure this makes sense. In Fedora, we just carve up the files at the RPM level and trying to do this in a cross-distro manner will be difficult if not impossible. Since I opened it, I'm going to close it but if anyone feels like it's important, feel free to re-open. It should be doable in a cross-distro manner. ${destDir} can be used for selecting different locations for installation.
You can create separate ant targets (install-swt, install-rcp) to install the parts. The install target will call those too.
After discussing this with Benjamin on IRC, we've decided that the best say to do this in a distro-agnostic way is to create files during the build that will list what parts of the installation go into which distribution package. The existing Debian .install files are related: http://git.debian.org/?p=pkg-java/eclipse.git;a=tree;f=debian;h=78ab5190ade12465973a88000e15a071dfbaf482;hb=HEAD Benjamin/Niels: how do Debian .install files indicate the case where a package should own _just_ a directory but not its contents? In RPM-land, one would do the following: %dir <some directory> This is needed for the case of the SWT package being installed at the "lowest" level and thus owning the 'configuration' directory but still allowing for packages "above" SWT such as RCP to put stuff into that directory. /usr/lib/eclipse/configuration <-- owned by SWT /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles <-- owned by SWT /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles/<SWT bundle ID> <-- owned by SWT /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles/<o.e.c.filesystem bundle ID> <-- owned by RCP We don't add empty directories to packages. Your example implemented in Debian: SWT package: contains nothing RCP package: contains the file /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles/<o.e.c.filesystem bundle ID> Why do you want an empty directory in the SWT package? I don't want the file /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles owned by both packages. According to your example /usr/lib/eclipse/configuration/org.eclipse.osgi/bundles should be a directory or am I wrong? You can't have a directory and a file with the same name. To clarify the situation a bit; in Debian a directory can have multiple owners; the package system will keep the directory as long as one package "owning" it is installed. I am not even sure it is possible to force a single package to own the directory as long as another package as something installed beneath that directory. These install files therefore do not have a way of declaring ownership of a given directory. Perhaps we can have a secondary/optional way of listing "non-trivial" ownership of directories for distributions that need it? ~Niels RPM can have multiple owners for a directory, too. I'll think about this some more and try to come up with something but I don't think I'll have much time in the near future so would greatly appreciate some help here. If you're interested, you can see which files are in which Fedora package here: http://koji.fedoraproject.org/koji/buildinfo?buildID=188753 Click on the 'info' link next to each .rpm (you can ignore the -debuginfo one). How about creating two files for each package? One contains a list of files and the other a list of directories that should be part of the package. That sounds like an alright approach, Benjamin. I will be unable to work on this for the foreseeable future, though, so please proceed without me. Eclipse build system has changed and eclipse-build will serve only as a helper. There will be no logic there. |