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

Re: main or contrib?



On Fri, Oct 27, 2006 at 08:13:38AM +0900, Charles Plessy wrote:
> Le Thu, Oct 26, 2006 at 03:30:50PM +0200, Thibaut Paumard a ?crit :
> > Charles Plessy <charles-debian-nospam@plessy.org> wrote:
> > > Examples of packages which would be included in contrib are:
> > >     * free packages which require [...] packages which
> > >       are not in our archive at all for compilation or execution
> > 
> > So yes, you can put in contrib free bits of software that depend on things
> > not in Debian to function.
> 
> well, I am wondering what this really means :
> 
> - If a package in contrib depends on a package which is absent of the
>   Debian archives, how can it be autobuilt?

If a package has non-free build-dependencies, it depends on the non-freeness
of them.  The resulting package must be distributable, of course (otherwise it
cannot be distributed even in non-free, let alone contrib).  For example, if
it needs to link to a non-free library (which is distributed in non-free), I
suppose the build-dependency for it will be satisfied (from non-free) by the
auto-builder.  If there is a build-dependency on non-free stuff not in Debian,
that stuff needs to be included in the source package, which makes the package
non-free, I suppose (but the resulting binary package may be contrib anyway).

But often, for the example given here, the dependency is at run-time, not at
build time.  So the package can build without a problem, but it is not useful
without some stuff not in Debian (free or not).  In such a case, autobuilding
is obviously not a problem.

> If it cannot build, can it be released?

Yes.  There is no rule that everything in Debian must be built from source,
even for main.  It is considered good practise to build things from source,
and it is in particular needed if the result is different on different
architectures.  However, if the non-free parts are only available for i386
(which is usual), it isn't strictly needed, just good.  Whether or not it can
be released is a legal matter, not a technical one.

> In the past Pine was only released as a source package, but I do not know
> what is the general feeling about this now.

Yes, Pine has a license which allows distribution of the source, but not of
modified binaries.  This is not a standard thing, it's just Pine's license.

> - The policy still mentions dependancies about packages, not about
>   software.

If software is not packaged, I suppose it is the same as when it would be
packaged, but the package isn't in Debian.

>   Does it mean that the upload of packages which can not be built or used
>   using commands like dpkg, apt, or aptitude, as opposed to make, is
>   discouraged?

I don't quite understand what you mean.  Any build process can be wrapped into
dpkg-buildpackage (although the "upstream" source may need to be repackaged in
some cases).  That is, if you can build the package "manually", you can also
write a debian/rules file to do it automatically.  A Debian package can always
be used using dpkg, apt and aptitude, otherwise it isn't a Debian package.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: