[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Looking for help towards my first Debian package (ITP#962603)

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.


> 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.


> 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.



Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: