Re: compiled binary file in source package
Miroslav Kravec writes: > On Fri, Feb 9, 2018 at 10:02 AM, Ben Finney wrote: > > I'm not sure I understand the question. I think you are asking about > > general-purpose, third-party-maintained development tools. > > > > If so: yes, the recommendation is that third-party-maintained > > software should not be bundled, but instead packaged for general use > > in a separate Debian package. […] > > Well, policy > https://www.debian.org/doc/debian-policy/#convenience-copies-of-code > says, that a package should not include convenience copies of > software, for which there's already a package in Debian archive. The section, §4.13 at the URL you cite, states: […] Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. That's essentially what I paraphrased in my message, quoted above. > > If you mean something different, can you clarify? > > I mean, whether Debian community officially encourages developers to > have their software packaged, if there's no technical need to include > their software as convenience copy. The Debian Wiki has an Upstream Guide, which discusses our expectations for upstream releases of works. The discussion of the source tarball https://wiki.debian.org/UpstreamGuide#Source_only_tarball> has the request you're asking about, I think. -- \“If the arguments in favor of atheism upset you, explain why | `\they’re wrong. If you can’t do that, that’s your problem.” | _o__) —Amanda Marcotte, 2015-02-13 | Ben Finney
Re: compiled binary file in source package
On Fri, Feb 9, 2018 at 10:02 AM, Ben Finney wrote: > Miroslav Kravec writes: > >> On Fri, Feb 9, 2018 at 9:38 AM, Paul Wise wrote: >> > https://wiki.debian.org/EmbeddedCodeCopies >> >> And, is there any official recommendation to get software (development >> tools) rather packaged, and used as build dependency, than being >> copied? > > I'm not sure I understand the question. I think you are asking about > general-purpose, third-party-maintained development tools. > > If so: yes, the recommendation is that third-party-maintained software > should not be bundled, but instead packaged for general use in a > separate Debian package. That's what the document at the above URL is > discussing; it includes a link to the relevant Debian Policy section. Well, policy https://www.debian.org/doc/debian-policy/#convenience-copies-of-code says, that a package should not include convenience copies of software, for which there's already a package in Debian archive. > If you mean something different, can you clarify? I mean, whether Debian community officially encourages developers to have their software packaged, if there's no technical need to include their software as convenience copy.
Re: compiled binary file in source package
On 10.02.2018 00:43, Ben Finney wrote: > David Rabel writes: >> On 09.02.2018 00:44, Ben Finney wrote: >>> Is the compiled binary file generated entirely from sources that are >>> all in the upstream source distribution? >> >> Yes, it's genereated from the sources. Allthough I cannot technically >> verify that. > > That will be a necessary part of the Debian packaging work: you'll need > to ensure the build process of the work from its source, in a way that > others can also replicate from your packaging. > > In other words: When you omit the bundled file from the source package, > and re-generate the equivalent from the source files, that will > demonstrate whether or not there are significant differences in the > original bundled file. > The binary in the source package does not equal the binary I generate when building the package 'bit for bit'. Still I don't really think that the upstream put any different binary inside the package. But since I cannot verify it (or it's not worth the effort), I just want to delete the binary. >>> Is the compiled binary file needed at all — can it be removed without >>> detriment for generating the Debian package from source? >> >> It can be removed, yes. It is recompiled during the build processs >> anyways. > > Do you know that the file is re-compiled from entirely DFSG-compliant > source? > Yes. > If the answer is no, then (that part of) the work is not free software, > so removing it would justify a ‘+dfsg.1’ suffix on the re-packed source. > > If the answer is yes, and there are no other DFSG problems, the > re-packed source should probably get ‘+ds.1’ suffix. > Thanks. I will use +ds.1 then. David signature.asc Description: OpenPGP digital signature
Re: compiled binary file in source package
David Rabel writes: > On 09.02.2018 00:44, Ben Finney wrote: > > Is the compiled binary file generated entirely from sources that are > > all in the upstream source distribution? > > Yes, it's genereated from the sources. Allthough I cannot technically > verify that. That will be a necessary part of the Debian packaging work: you'll need to ensure the build process of the work from its source, in a way that others can also replicate from your packaging. In other words: When you omit the bundled file from the source package, and re-generate the equivalent from the source files, that will demonstrate whether or not there are significant differences in the original bundled file. > > Is the compiled binary file needed at all — can it be removed without > > detriment for generating the Debian package from source? > > It can be removed, yes. It is recompiled during the build processs > anyways. Do you know that the file is re-compiled from entirely DFSG-compliant source? If the answer is no, then (that part of) the work is not free software, so removing it would justify a ‘+dfsg.1’ suffix on the re-packed source. If the answer is yes, and there are no other DFSG problems, the re-packed source should probably get ‘+ds.1’ suffix. > Yes, that's sounds good. Which suffix is best-fitting? +dfsg ? I'm > uncertain, since the file is very probably free software. As a separate matter, you will want to have good documentation in ‘debian/copyright’ showing that the work is in fact free software when recompiled and redistributed in Debian. -- \ “Capitalism is the astounding belief that the most wickedest of | `\men will do the most wickedest of things for the greatest good | _o__) of everyone.” —John Maynard Keynes | Ben Finney
Re: compiled binary file in source package
On 09.02.2018 00:44, Ben Finney wrote: > David Rabel writes: > >> I am maintaining jugglinglab. The upstream source package contains a >> compiled binary file. What is the cleanest solution to get rid of it? > > Is the compiled binary file generated entirely from sources that are all > in the upstream source distribution? Yes, it's genereated from the sources. Allthough I cannot technically verify that. > Is the compiled binary file needed at all — can it be removed without > detriment for generating the Debian package from source? It can be removed, yes. It is recompiled during the build processs anyways. > Probably the best option is to re-pack the source to exclude that file > https://pkg-perl.alioth.debian.org/howto/repacking.html>. Yes, that's sounds good. Which suffix is best-fitting? +dfsg ? I'm uncertain, since the file is very probably free software. I just don't want to have precomiled binary files inside the source package. David signature.asc Description: OpenPGP digital signature
Re: compiled binary file in source package
Miroslav Kravec writes: > On Fri, Feb 9, 2018 at 9:38 AM, Paul Wise wrote: > > https://wiki.debian.org/EmbeddedCodeCopies > > And, is there any official recommendation to get software (development > tools) rather packaged, and used as build dependency, than being > copied? I'm not sure I understand the question. I think you are asking about general-purpose, third-party-maintained development tools. If so: yes, the recommendation is that third-party-maintained software should not be bundled, but instead packaged for general use in a separate Debian package. That's what the document at the above URL is discussing; it includes a link to the relevant Debian Policy section. If you mean something different, can you clarify? -- \ “Skepticism is the highest duty and blind faith the one | `\ unpardonable sin.” —Thomas Henry Huxley, _Essays on | _o__) Controversial Questions_, 1889 | Ben Finney
Re: compiled binary file in source package
On Fri, Feb 9, 2018 at 9:38 AM, Paul Wise wrote: >> I got interested in this, as I want to use a tool, which isn't >> packaged in debian. And upstream considers it to be a good idea to >> include tool's sources into project, where it's used. I like more >> clean solution - get the tool packaged into debian, then use the tool >> in my project. > > That is a different scenario, it is an embedded code copy: > > https://wiki.debian.org/EmbeddedCodeCopies And, is there any official recommendation to get software (development tools) rather packaged, and used as build dependency, than being copied?
Re: compiled binary file in source package
On Fri, Feb 9, 2018 at 4:14 PM, Miroslav Kravec wrote: > Could you please provide the name of the policy? I've just read it, > and I haven't found one. Debian Free Software Guidelines item 2: https://www.debian.org/social_contract#guidelines 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. > - Generated files, which is fine, as long as there's corresponding > original form In general, these should be removed from the upstream VCS and tarballs and always built from the source. Exceptions may apply, for example: When the build takes a month or longer, but the build results should ship in separate tarballs to source. When the build requires specific hardware, but the build results should ship in separate tarballs to source. autotools, but packages should autoreconf. Personally, I would like to autotools move to a model of shipping the autoreconf results in a separate tarball. > - Source missing, which is fine too, because it's not missing, it's in > package This isn't ideal because it usually results in static linking, which means keeping track of when to rebuild the packages using the source, which Debian does not yet do. > I got interested in this, as I want to use a tool, which isn't > packaged in debian. And upstream considers it to be a good idea to > include tool's sources into project, where it's used. I like more > clean solution - get the tool packaged into debian, then use the tool > in my project. That is a different scenario, it is an embedded code copy: https://wiki.debian.org/EmbeddedCodeCopies -- bye, pabs https://wiki.debian.org/PaulWise
Re: compiled binary file in source package
On Fri, Feb 9, 2018 at 5:14 AM, Ben Finney wrote: > A source package that contains a file that requires source not in Debian > is one of the reasons given by FTP masters for rejecting a source > package https://ftp-master.debian.org/REJECT-FAQ.html>, as a > “serious violation” of Debian policy. Could you please provide the name of the policy? I've just read it, and I haven't found one. I found: - Generated files, which is fine, as long as there's corresponding original form - Source missing, which is fine too, because it's not missing, it's in package I got interested in this, as I want to use a tool, which isn't packaged in debian. And upstream considers it to be a good idea to include tool's sources into project, where it's used. I like more clean solution - get the tool packaged into debian, then use the tool in my project.
Re: compiled binary file in source package
Wookey writes: > Is it actually doing any harm? Does it get included in the package? > Does it get rebuilt? If it gets rebuilt then just remove it in the > clean rule. If it doesn't get included then you could just ignore > it. That's not sufficient. If a source package contains an auto-generated file, that file needs corresponding source in Debian (typically in the same source package). A source package that contains a file that requires source not in Debian is one of the reasons given by FTP masters for rejecting a source package https://ftp-master.debian.org/REJECT-FAQ.html>, as a “serious violation” of Debian policy. > It's not doing any harm, unless it's known to be non-free. Regardless of the license granted for the file, if the file is non-source (i.e. if it is not the preferred form of that work for making modifications), it should not be in the Debian source package. As Wookey points out, the best way to ensure that is to remove it from the source package when re-packing the source for Debian. -- \ “DRM doesn't inconvenience [lawbreakers] — indeed, over time it | `\ trains law-abiding users to become [lawbreakers] out of sheer | _o__)frustration.” —Charles Stross, 2010-05-09 | Ben Finney
Re: compiled binary file in source package
On 2018-02-08 23:46 +0100, David Rabel wrote: > Hi there, > > I am maintaining jugglinglab. The upstream source package contains a > compiled binary file. What is the cleanest solution to get rid of it? Is it actually doing any harm? Does it get included in the package? Does it get rebuilt? If it gets rebuilt then just remove it in the clean rule. If it doesn't get included then you could just ignore it. It's not doing any harm, unless it's known to be non-free. > Story behind that: > > When I started packaging jugglinglab in 2016 I just deleted the file > with a patch. > > This is unclean and for example sbuild refuses to build the package, > because it does a dh_clean before which also deletes the binary and then > complains that the patch cannot delete a file that isn't there. a '-' in front of a make command stops it erroring out. It is often appriate for clean rules that remove a file (it's fine if the deletion fails because the file is already not there) - rm foo You don't need the patch as well. Is that there because otherwise dpkg-source complains about changes? It should ignore removed files. > So, after more than a year, I think he won't answer. So I have to come > up with another solution. I just don't have an idea, what is the best > way to do that. Can you help me? Repacking the source without it is probably neatest. But just removing it in the clean rule is also fine. Or ignoring it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: compiled binary file in source package
David Rabel writes: > I am maintaining jugglinglab. The upstream source package contains a > compiled binary file. What is the cleanest solution to get rid of it? Is the compiled binary file generated entirely from sources that are all in the upstream source distribution? Is the compiled binary file needed at all — can it be removed without detriment for generating the Debian package from source? > When I started packaging jugglinglab in 2016 I just deleted the file > with a patch. > > This is unclean and for example sbuild refuses to build the package, > because it does a dh_clean before which also deletes the binary and > then complains that the patch cannot delete a file that isn't there. Probably the best option is to re-pack the source to exclude that file https://pkg-perl.alioth.debian.org/howto/repacking.html>. -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney
