I've been trying out wpkg on CentOS, and so far it's very nice.
One issue I ran into is that symlinks are silently ignored when building packages. This is somewhat unfortunate, because the standard practice for linux is to have a shared library symlink from the major version to the specific version. Would it be difficult to add this functionality?
Best,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main aim of wpkg is to build packages that will work under MS-Windows, and MS-Windows is notorious for not supporting symbolic links. That being said, since Win7, we have such support so I could imagine we could look into having support for symbolic links now. Yet, not very many Windows users use such, I would imagine...
Obviously, binary packages would only work in Windows or Linux (or some other Unix platform) and not both platforms. That being said, with Wine, you could install Windows binaries and still run that code on your Linux system.
Last edit: Alexis Wilke 2015-07-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Btw, a way to palliate with the current version is to write a postinst script and creates the link "manually". Then create a postrm script to delete the link when the package gets purged (or use prerm to remove it when just uninstalling).
the resulting package includes the real files but not the symlinks. "wpkg --contents foo.deb" does not list the symlink, and installing the package does not install the symlink.
The reason for my interest is that we're exploring a multi-platform package structure where software is distributed as a combination of platform independent (for java, .net, python, ...) and platform dependent (natively compiled C++) packages. So, each platform (windows, linux, macos) would have a few platform independent packages and a few platform-dependent packages. wpkg's multi-platform support is a significant strength.
| ... a way to palliate with the current version is to write a postinst script ...
I was hoping to avoid this. From my experience with rpm and dpkg, these untracked files are never managed as well as when they're part of the package's file list.
Best,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Potentially, though I'm not familiar with the code base. Do the .deb package data structures already include symlink representation? (I assume dpkg supports symlinks.)
I can certainly work out the system calls to read / create the symlinks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been trying out wpkg on CentOS, and so far it's very nice.
One issue I ran into is that symlinks are silently ignored when building packages. This is somewhat unfortunate, because the standard practice for linux is to have a shared library symlink from the major version to the specific version. Would it be difficult to add this functionality?
Best,
Mark
Do you mean that wpkg does not generate the symlinks, or that your
package has symlinks that aren't included in the final output?
Last edit: Alexis Wilke 2015-07-21
The main aim of wpkg is to build packages that will work under MS-Windows, and MS-Windows is notorious for not supporting symbolic links. That being said, since Win7, we have such support so I could imagine we could look into having support for symbolic links now. Yet, not very many Windows users use such, I would imagine...
Obviously, binary packages would only work in Windows or Linux (or some other Unix platform) and not both platforms. That being said, with Wine, you could install Windows binaries and still run that code on your Linux system.
Last edit: Alexis Wilke 2015-07-21
Btw, a way to palliate with the current version is to write a postinst script and creates the link "manually". Then create a postrm script to delete the link when the package gets purged (or use prerm to remove it when just uninstalling).
See here:
http://windowspackager.org/documentation/implementation-details/scripts-and-processes
Last edit: Alexis Wilke 2015-07-21
| Do you mean that wpkg does not generate the symlinks..
When I build a package on linux from a directory tree that includes both real files and symlinks:
WPKG/control
lib/libfoo.so.1
lib/libfoo.so -> libfoo.so.1
the resulting package includes the real files but not the symlinks. "wpkg --contents foo.deb" does not list the symlink, and installing the package does not install the symlink.
The reason for my interest is that we're exploring a multi-platform package structure where software is distributed as a combination of platform independent (for java, .net, python, ...) and platform dependent (natively compiled C++) packages. So, each platform (windows, linux, macos) would have a few platform independent packages and a few platform-dependent packages. wpkg's multi-platform support is a significant strength.
| ... a way to palliate with the current version is to write a postinst script ...
I was hoping to avoid this. From my experience with rpm and dpkg, these untracked files are never managed as well as when they're part of the package's file list.
Best,
Mark
I agree with you, Mark, that wpkg should respect symlinks on those
platforms that support them.
Would you be interested in writing a patch?
| Would you be interested in writing a patch?
Potentially, though I'm not familiar with the code base. Do the .deb package data structures already include symlink representation? (I assume dpkg supports symlinks.)
I can certainly work out the system calls to read / create the symlinks.
Yes, it uses the "tar" format which includes support for symlinks.