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

Re: oaklisp: contains 500kB binary in source

I'm confused as to the concern here.  When one grabs the source for this 
package do they have all the necessary tools to build that package?  If the 
answer is yes, then what potential DFSG issues exist?

I haven't inspected the package myself, but I'm willing to bet that the source 
for the 500KB binary is also there, which should allow someone to modify the 
source and create a NEW 500KB binary, should they so desire.  This doesn't 
seem to be a limitation on the user as no rights, at least that I'm aware of, 
are being denied.  Modification, distribution, use...  they're all there 
provided one minor *technical* inconvenience.

We may wish, from a technical perspective, that we could build this package 
from the ground up without such a recursive bootstrap process, but such a 
request seems far beyond debian-legal's scope of review.


On Monday 07 June 2004 08:41 am, Edmund GRIMLEY EVANS wrote:
> Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
> > > GHC seems to be in the same situation: there are other implementations
> > > of Haskell, but GHC uses some GHC-specific features, so you have to
> > > compile it with GHC.
> >
> > GHC can be bootstrapped without GHC itself, there is a minimal C
> > implementation of the necessary code. No need to build-depend on itself.
> Are you referring to the use of HC files in porting GHC?
> http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html
> > I notice the GHC maintainer somehow doesn't use this possibility, I
> > don't know why, it makes bootstrapping GHC difficult.
> Debian packages should probably be built from source as a matter of
> principle. The HC files are automatically generated (using GHC) and
> should not be counted as source.
> However, maybe for convenience the Debian package could have an option
> to use the HC files.
> > > I assume that cyclic Build-Depends are acceptable in Debian. It would
> > > be difficult if they weren't.
> >
> > For essential packages, build-essential and kernels (not in the sense
> > one build-depends on a kernel, but one requires a working kernel before
> > running the build), it's understandable. For everything else, I consider
> > that quite wierd.
> I'm not sure about that. It's fairly normal for people to implement
> compilers in the same language and I don't see why they should be
> expected to provide a bootstrap path using C.
> There's also the case of Build-Depends cycles caused by non-essential
> parts of a package, such as the documentation. If a documentation
> preparation system uses some library, and the author of that library
> decides to use that documentation preparation system for the library
> documentation, then there will be a cycle, but one that is easily
> avoided by just not building the documentation the first time.

Sean Kellogg
1st Year - UW Law School
c: 206.498.8207    e: skellogg@u.washington.edu
w: http://www.livejournal.com/users/economyguy/  <-- lazy mans blog

"When the only tool you have is a hammer, you tend to treat everything
as if it were a nail."
     -- Abraham Maslow

Reply to: