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

Bug#392362: [PROPOSAL] Add should not embed code from other packages



On Mon, Jun 25, 2007 at 02:02:21PM +0100, Neil McGovern wrote:
> On Mon, Jun 18, 2007 at 07:27:43PM +0200, Bill Allombert wrote:
> > On Mon, Jun 18, 2007 at 03:59:12PM +0200, Stefan Fritsch wrote:
> > > I second Neil's proposal from Sun, 15 Oct 2006 09:49:58, i.e. the 
> > > latest version.
> > 
> > and I have to object to it because the proposal seems to mix build-time
> > and run-time dependencies. At least I did not get an answer to my later
> > post on the subject. It should be clarified whether the proposal apply
> > to source packages and build-dependencies or binary packages and 
> > run-time dependencies.
> > 
> 
> I don't think it does. The proposal is for source packages, and a
> run-time (well, install time) dependancy should be declared on the
> relevent lib* package. I'm not sure there's a need to explicitly state
> that a lib*-dev builddep should be declared, as the package will FTBFS
> if it can't find that libraries it needs.
> 
> Any suggestions for improved wording?

If this is that what you want, then I will certainly not object, but the
current draft seems to imply something else. Especially the expected 
meaning of package does not seems to capture what you need.

I think you should clarify that:

1) This is meant to apply to source packages where upstream include
convenience copy of external libraries (in the large sense) that are
normally distributed as stand-alone tarball, and where the build-process
link against the convenience copy of the libraries (instead of the system one).

2) The package should build against the libraries as provided by Debian
and not the convenience copy. Preferably, the convenience copy should
not even be compiled in the build-process.

> > +    <sect id="embeddedfiles">
> > +      <heading>Embedding code provided in other packages</heading>
> > +      <p>
> > +      A package should not embed or include code from other
> > +      packages. Instead, the package should be modified to reference the
> > +      required files provided by the other package, and a Depends
> > +      relationship declared.</p>
> > +      </sect>
> >      </chapt>

Suppose the upstream tarball of foo include a copy of libjpeg and link
statically the program against it. It is not obvious that
"package foo embed or include code from package libjpeg". Some
one could think "precisely it doesn't since it uses its own copy of
libjpeg".  

On the other hand, bar is compiled staticaly against libjpeg. I am
sure some one would say "bar include code from libjpeg".

By no mean do I want to encourage static linking, but it does not
seems to be what you had in mind, and forbidding static linking
has other issues that it is best to address separately.
In any case it is too generic this way.

> And I did reply to your last mail, copying here at the end :)

Sorry I missed it, then.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Reply to: