Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOURCE contains BINARIES #173

Open
lkairies opened this issue Jun 3, 2014 · 1 comment

Comments

Projects
None yet
2 participants
@lkairies
Copy link
Contributor

commented Jun 3, 2014

From phob...@googlemail.com on December 07, 2010 18:46:40

What steps will reproduce the problem? The following pre-compiled binary-jar-files are part of the source distribution:
src/servers/dist/XtreemFS.jar
src/servers/lib/BabuDB.jar
src/servers/lib/test/commons-codec-1.3.jar
src/servers/lib/test/commons-httpclient-3.0.1-contrib.jar
src/servers/lib/test/commons-httpclient-3.0.1.jar
src/servers/lib/test/commons-logging-1.1.jar
src/servers/lib/test/junit-4.3.1.jar
src/servers/lib/yidl.jar
src/servers/xtreemos/bcprov-jdk16-139.jar
src/servers/xtreemos/cdaclient.jar What is the expected output? What do you see instead? Move all jar-files to get a real source-package.

Provide the source-code used to build those binaries or describe a way to get the identical source-code from upstream. The upstream source has moved along and its trunk "might" not be usable.

Updated to the latest versions of the upstream packages.

Build the needed jar-files during the build-process of xtreemfs
or put the binaries and its source into separate archives.

I would prefer separate source-packages without binaries but with makefiles. This would make syncing with upstream easier. What version of the product are you using? On what operating system? 1.2.3
Debian/sid

Original issue: http://code.google.com/p/xtreemfs/issues/detail?id=173

@onlyjob

This comment has been minimized.

Copy link
Contributor

commented Dec 22, 2014

I couldn't agree more but unfortunately XtreemFS developers ignore even more serious issue with OpenDMK dependency which is non-free and unmaintained since 2007, see #309.

As part of my evaluation of XtreemFS I prepared updated packaging where many bundled JARs were ripped-off (as per Debian policy) but not all of them. I've dumped my draft packaging to
https://github.com/onlyjob/xtreemfs/commits/debian
where I'm going to leave it (it's too much for pull request).
It is already much better than sloppy upstream packaging but still unfinished...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.