Difference between revisions of "Talk:Create a package (tarball) for distribution"

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search
(Discussion about sense ornonsense of pack_sync tool:)
 
m
 
Line 1: Line 1:
Discussion about sense ornonsense of pack_sync tool:
+
Discussion about sense or nonsense of pack_sync tool:
  
 
"Only in case that you're not using PACKAGE but another name you have to specify this. The script takes a walk thru the directory tree calling itself recursively. It compares all files with those of the living system (same directory path but w/o prefix <current-directory>/PACKAGE). If there are differences you are prompted to confirm a replacement. If you are not sure: Deny the replacement. Get informed about the differences. You may not want to replace configuration files if those of the living system contain personal data. But if you want the replacement, just run pack_sync again. Note that pack_sync may be called as often as you like but it doesn't have an undo."
 
"Only in case that you're not using PACKAGE but another name you have to specify this. The script takes a walk thru the directory tree calling itself recursively. It compares all files with those of the living system (same directory path but w/o prefix <current-directory>/PACKAGE). If there are differences you are prompted to confirm a replacement. If you are not sure: Deny the replacement. Get informed about the differences. You may not want to replace configuration files if those of the living system contain personal data. But if you want the replacement, just run pack_sync again. Note that pack_sync may be called as often as you like but it doesn't have an undo."

Latest revision as of 22:48, 27 February 2007

Discussion about sense or nonsense of pack_sync tool:

"Only in case that you're not using PACKAGE but another name you have to specify this. The script takes a walk thru the directory tree calling itself recursively. It compares all files with those of the living system (same directory path but w/o prefix <current-directory>/PACKAGE). If there are differences you are prompted to confirm a replacement. If you are not sure: Deny the replacement. Get informed about the differences. You may not want to replace configuration files if those of the living system contain personal data. But if you want the replacement, just run pack_sync again. Note that pack_sync may be called as often as you like but it doesn't have an undo."

==> This doesn't make sense. The mentioned tool does not change any hard-coded pathes compiled into binaries. These are, however, the ones who make trouble. Applications use hard coded pathes to find other component of themselves. This is not the cleverest idea, but many do. E.g. gcc does this. That is the reason why an applications must be compiled for the place where it will finally be installed. You can't compile this stuff for another location and fix it afterwards [well, in theory you can, but that is a tricky procedure, reshuffling the contents of object files)]. You either have a build system which supports this (e.g. a GNU build system), or you have to hack the build system until it complies. Running a diff on the binaries later will not fix the problem.

==> ls2newbee: Sorry if I wasn't clear enough. pack_sync does not patch any files. The idea was to install the package first to the running system. These files wil reside there where they shouldbe at any other installation. In a second step the whole installation is done again from scratch now targeting to a PACKAGE directory for creation of a tarball of compiled executables. This second make may compile wrong pathnames because the files actually do not reside where they should be on the target system (as on any system). So pack_sync is able to replace the files in the PACKAGE directory (having wrong hard coded path names) by the files of the first installation (having correct hard coded path names). For this purpose it compares files of the 2nd 'tarball' installation with the corresponding files of the 1st 'real' installation. The result is - in theory - a tarball with correct path names because the files are actually taken from the living system (i.e. from the first installaion).

In other words: If pack_sync replaced *all* files by those of the running system (correct paths!), you'd get a correct tarball. However there is no need to replace files if there is no difference.

If you have any questions, please feel free to send me a private message.