Re: Source requirements and debian/missing-sources/ (was: "Browserified" stuff)

[W. Martin Borgert]

On 2016-10-12 21:22, Adam Borowski wrote:
> On Wed, Oct 12, 2016 at 09:00:50PM +0200, W. Martin Borgert wrote:
> > Who cares about yaccs and
> > bisons?
>
> You're thinking small.  Why not ship a pre-compiled ELF, built with some
> paid version of ICC (screw silly sods on AMD chips like me[1]).

I was planning this, but was not aware of a compiler that
produces multi-arch binaries for all eleven architectures.
Thanks for solving my problem :~)

> > If I understand correctly, and please correct me if I'm wrong, this
> > directory is for sources of files that are in your source package, but
> > not in the binary.
> >
> > Example: A source package had an embedded source copy of B.min.js
> > (minified, non-source), but the binary package does not have it,
> > because A depends on libjs-B and has the right debian/links. Then you
> > can put the B source into As d/m-s. If B.min.js is actually used in A,
> > d/m-s is not sufficient. But maybe I'm on the wrong track...
>
> That's my understanding as well.

It seems neither tincho nor myself could find that codified.
There is only lintian...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8
talks specifically about minified JS, btw.

Re: Source requirements and debian/missing-sources/ (was: "Browserified" stuff)

[Adam Borowski]

On Wed, Oct 12, 2016 at 09:00:50PM +0200, W. Martin Borgert wrote:
> Quoting Martín Ferrari :
> >I had always understood that rebuilding from source was a hard
> >requirement. Is this not the case any more?
> >
> >I don't think that shipping a binary compiled upstream should be
> >allowed, so where's the line drawn?
> 
> This is an interesting question indeed.
> 
> If it is allowed for a package in main to ship a pre-compiled JS file
> with only some source files under debian/missing-sources/, it could be
> tempting to use all kind of pre-compiled *.c files in a package and do
> not care about a proper build process. Who cares about yaccs and
> bisons?

You're thinking small.  Why not ship a pre-compiled ELF, built with some
paid version of ICC (screw silly sods on AMD chips like me[1]).  Just think
of all that saved compilation time and avoided FTBFSes on new gcc versions!
Then you put a non-working dump of .c files, not necessarily the same as you
compiled, without a build system, into debian/missing-sources/ then never
update them.

> > I have never heard of debian/missing-sources. What is the
> > policy/documentation regarding this? I have repackaged tarballs many
> > times to add missing sources, I did not think there was another way to
> > do it!
>
> If I understand correctly, and please correct me if I'm wrong, this
> directory is for sources of files that are in your source package, but
> not in the binary.
>
> Example: A source package had an embedded source copy of B.min.js
> (minified, non-source), but the binary package does not have it,
> because A depends on libjs-B and has the right debian/links. Then you
> can put the B source into As d/m-s. If B.min.js is actually used in A,
> d/m-s is not sufficient. But maybe I'm on the wrong track...

That's my understanding as well.


[1]. ICC produces code that has different paths for different CPUs, using
optimized code when some instructions are available at runtime; when the
cpuid is not "GenuineIntel", it chooses a working but carefully deoptimized
variant despite the CPU having instructions that it wants.
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Source requirements and debian/missing-sources/ (was: "Browserified" stuff)

[W. Martin Borgert]

Quoting Martín Ferrari :

I had always understood that rebuilding from source was a hard
requirement. Is this not the case any more?

I don't think that shipping a binary compiled upstream should be
allowed, so where's the line drawn?


This is an interesting question indeed.

If it is allowed for a package in main to ship a pre-compiled JS file
with only some source files under debian/missing-sources/, it could be
tempting to use all kind of pre-compiled *.c files in a package and do
not care about a proper build process. Who cares about yaccs and
bisons?


I have never heard of debian/missing-sources. What is the
policy/documentation regarding this? I have repackaged tarballs many
times to add missing sources, I did not think there was another way to
do it!


If I understand correctly, and please correct me if I'm wrong, this
directory is for sources of files that are in your source package, but
not in the binary.

Example: A source package had an embedded source copy of B.min.js
(minified, non-source), but the binary package does not have it,
because A depends on libjs-B and has the right debian/links. Then you
can put the B source into As d/m-s. If B.min.js is actually used in A,
d/m-s is not sufficient. But maybe I'm on the wrong track...

Cheers