On Thu, 2020-06-11 at 02:53 -0400, Qianqian Fang wrote: > that's possible. however, some of the file release systems, such as > MATLAB File Exchange, only links to the github generated > master.zip/release packages. if I remove the mex files from my github > folder, users will not be able to run unless they know how to > recompile. I think I would just change the MATLAB download link to the github releases page, which then links to source/binaries for each release. > I did have a separate github repo for binaries, but it is quite > painful to sync and promote if I have two URLs. That doesn't seem like the correct solution to me, one should never keep generated nor bundled files in git. > for now, I will simply create a source-only orig.tar.gz file when I > upload my package again. Thanks. > I agree that library bundling is a bad thing only if such library is > widely available and frequently updated such as on Linux, but when > you aim to support users cross platforms (especially those using > windows), counting on users to install all dependencies and > successful compile your code is simply difficult. I suggest that users should be provided with pre-compiled binaries instead of source. On platforms that don't have sane dependency systems, you would obviously need to provide copies of all dependencies, but that should happen in the binary packages for those platforms, not in the source code repository. > Bundling lightweight dependencies (with a compatible license of > course) could potentially save lots of time and trouble. Pre-compiled binaries saves even more time. > Bundling also avoids a lot of instability issues when a library > decides to make a non-backward-compatible interface changes (which > happens quite often among linux libraries). Pre-compiled binaries avoids this too. For compiling from source you can add version constraints in most build systems, but eventually you just need to support newer the interface versions. > anyhow, my opinion is that while admitting bundling is not a best > practice, it is not something that should be forbidden either. If I > can't bundle lz4 source codes (4 files), then I will have to change > my upstream makefile and create a new release. For a library like lz4, with a small record of security issues, I don't think it is appropriate to statically link it nor embed copies of it unless of course the platform the binaries are for doesn't have a sane dependency system. For those platforms you need to ensure your binaries use the newest version of the library with no security bugs. If you are not embedding the library in your source code, a simple rebuild updates the binaries for those platforms but if you are embedding then you need to manually update the embedded version before you can rebuild and then release, so embedding libraries in your source is less efficient. https://security-tracker.debian.org/tracker/source-package/lz4 > the repo says public, can you try this link again? > > https://salsa.debian.org/fangq/libzmat I made a typo on your username, sorry. Looks like what you haven't isn't correct, it should be libzmat1 instead of libzmat in the control file, since the library package name is supposed to be based on the SONAME of the library. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part