You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Matt Foley (Created) (JIRA)" <ji...@apache.org> on 2012/02/08 09:31:59 UTC
[jira] [Created] (HADOOP-8037) Binary tarball does not preserve
platform info for native builds
Binary tarball does not preserve platform info for native builds
----------------------------------------------------------------
Key: HADOOP-8037
URL: https://issues.apache.org/jira/browse/HADOOP-8037
Project: Hadoop Common
Issue Type: Bug
Components: build
Affects Versions: 1.0.1
Reporter: Matt Foley
Assignee: Giridharan Kesavan
The source tarball uses "package" ant target, which includes both sets of native builds (32 and 64 bit libraries), under subdirectories that are named for the supported platform, so you can tell what they are.
The binary tarball uses the "bin-package" ant target, which projects both sets of native builds into a single directory, stripping out the platform names from the directory paths. Since the native built libraries have identical names, only one of each survives the process. Afterward, there is no way to know whether they are intended for 32 or 64 bit environments.
It seems to be done this way as a step toward building the rpm and deb artifacts. But the rpms and debs are self-identifying as to the platform they were built for, and contain only one set of libs each, while the binary tarball isn't. The binary tarball should have the same platform-specific subdirectories that the full tarball does; but this means that the rpm and deb builds have to be more careful about include/exclude specs for what goes into those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-8037) Binary tarball does not preserve
platform info for native builds, and RPMs fail to provide needed symlinks
for libhadoop.so
Posted by "Matt Foley (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Foley resolved HADOOP-8037.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.0.1
> Binary tarball does not preserve platform info for native builds, and RPMs fail to provide needed symlinks for libhadoop.so
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-8037
> URL: https://issues.apache.org/jira/browse/HADOOP-8037
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Affects Versions: 1.0.1
> Reporter: Matt Foley
> Assignee: Giridharan Kesavan
> Priority: Blocker
> Fix For: 1.0.1
>
> Attachments: hadoop-8027-1.patch, hadoop-8037-1.patch, hadoop-8037.patch
>
>
> The source tarball uses "package" ant target, which includes both sets of native builds (32 and 64 bit libraries), under subdirectories that are named for the supported platform, so you can tell what they are.
> The binary tarball uses the "bin-package" ant target, which projects both sets of native builds into a single directory, stripping out the platform names from the directory paths. Since the native built libraries have identical names, only one of each survives the process. Afterward, there is no way to know whether they are intended for 32 or 64 bit environments.
> It seems to be done this way as a step toward building the rpm and deb artifacts. But the rpms and debs are self-identifying as to the platform they were built for, and contain only one set of libs each, while the binary tarball isn't. The binary tarball should have the same platform-specific subdirectories that the full tarball does; but this means that the rpm and deb builds have to be more careful about include/exclude specs for what goes into those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-8037) Binary tarball does not preserve
platform info for native builds, and RPMs fail to provide needed symlinks
for libhadoop.so
Posted by "Matt Foley (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Foley resolved HADOOP-8037.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.0.1
Committed to branch-1 and branch-1.0.
> Binary tarball does not preserve platform info for native builds, and RPMs fail to provide needed symlinks for libhadoop.so
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-8037
> URL: https://issues.apache.org/jira/browse/HADOOP-8037
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Affects Versions: 1.0.1
> Reporter: Matt Foley
> Assignee: Matt Foley
> Priority: Blocker
> Fix For: 1.0.1
>
> Attachments: hadoop-8027-1.patch, hadoop-8037-1.patch, hadoop-8037-2.patch, hadoop-8037.patch
>
>
> The source tarball uses "package" ant target, which includes both sets of native builds (32 and 64 bit libraries), under subdirectories that are named for the supported platform, so you can tell what they are.
> The binary tarball uses the "bin-package" ant target, which projects both sets of native builds into a single directory, stripping out the platform names from the directory paths. Since the native built libraries have identical names, only one of each survives the process. Afterward, there is no way to know whether they are intended for 32 or 64 bit environments.
> It seems to be done this way as a step toward building the rpm and deb artifacts. But the rpms and debs are self-identifying as to the platform they were built for, and contain only one set of libs each, while the binary tarball isn't. The binary tarball should have the same platform-specific subdirectories that the full tarball does; but this means that the rpm and deb builds have to be more careful about include/exclude specs for what goes into those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (HADOOP-8037) Binary tarball does not preserve
platform info for native builds, and RPMs fail to provide needed symlinks
for libhadoop.so
Posted by "Matt Foley (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Foley reopened HADOOP-8037:
--------------------------------
Regrettably, I have to revert this patch. I didn't notice it before, but the sizes of the resulting rpm and bin-tarball files are greatly increased due to duplicated files. We have to try again:
{code}
pre-patch sizes:
-rw-r--r-- 1 hortonfo users 31975332 Jan 31 02:42 hadoop_1.0.1-1_amd64.deb
-rw-r--r-- 1 hortonfo users 32039471 Jan 31 02:40 hadoop-1.0.1-1.amd64.rpm
-rw-r--r-- 1 hortonfo users 35909710 Jan 31 02:35 hadoop_1.0.1-1_i386.deb
-rw-r--r-- 1 hortonfo users 35974659 Jan 31 02:34 hadoop-1.0.1-1.i386.rpm
-rw-r--r-- 1 hortonfo users 31965140 Jan 31 02:41 hadoop-1.0.1-bin.tar.gz
-rw-r--r-- 1 hortonfo users 60322619 Jan 31 02:39 hadoop-1.0.1.tar.gz
post-patch sizes:
-rw-r--r-- 1 hortonfo users 93729906 Feb 9 03:38 hadoop_1.0.1-1_amd64.deb
-rw-r--r-- 1 hortonfo users 40754076 Feb 9 03:36 hadoop-1.0.1-1.amd64.rpm
-rw-r--r-- 1 hortonfo users 101357042 Feb 9 03:29 hadoop_1.0.1-1_i386.deb
-rw-r--r-- 1 hortonfo users 48735998 Feb 9 03:27 hadoop-1.0.1-1.i386.rpm
-rw-r--r-- 1 hortonfo users 66467789 Feb 9 03:38 hadoop-1.0.1-bin.tar.gz
-rw-r--r-- 1 hortonfo users 60782862 Feb 9 03:34 hadoop-1.0.1.tar.gz
pre-patch file counts:
445 hadoop-1.0.1-1.amd64.rpm
445 hadoop-1.0.1-1.i386.rpm
330 hadoop-1.0.1-bin.tar.gz
6974 hadoop-1.0.1.tar.gz
post-patch file counts:
789 hadoop-1.0.1-1.amd64.rpm
792 hadoop-1.0.1-1.i386.rpm
668 hadoop-1.0.1-bin.tar.gz
6978 hadoop-1.0.1.tar.gz
{code}
> Binary tarball does not preserve platform info for native builds, and RPMs fail to provide needed symlinks for libhadoop.so
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-8037
> URL: https://issues.apache.org/jira/browse/HADOOP-8037
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Affects Versions: 1.0.1
> Reporter: Matt Foley
> Assignee: Giridharan Kesavan
> Priority: Blocker
> Attachments: hadoop-8027-1.patch, hadoop-8037-1.patch, hadoop-8037.patch
>
>
> The source tarball uses "package" ant target, which includes both sets of native builds (32 and 64 bit libraries), under subdirectories that are named for the supported platform, so you can tell what they are.
> The binary tarball uses the "bin-package" ant target, which projects both sets of native builds into a single directory, stripping out the platform names from the directory paths. Since the native built libraries have identical names, only one of each survives the process. Afterward, there is no way to know whether they are intended for 32 or 64 bit environments.
> It seems to be done this way as a step toward building the rpm and deb artifacts. But the rpms and debs are self-identifying as to the platform they were built for, and contain only one set of libs each, while the binary tarball isn't. The binary tarball should have the same platform-specific subdirectories that the full tarball does; but this means that the rpm and deb builds have to be more careful about include/exclude specs for what goes into those artifacts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira