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

Proposed amendment (compiling non-free packages from source in main)



Hello,

I was going to over gdk-imlib from Shaleh so I can release Gnome 0.20,
and I encountered this policy issue.  (Shaleh may be keeping gdk-imlib
now)

One of the outstanding bugs is #22096, where James Troup complains
that gdk-imlib depends on a non-free library to build (giflib, for the
non-free binary package), which is a violation of policy.

Policy says:

 2.1.2 The main section

   Every package in "main" must comply with the DFSG (Debian Free
   Software Guidelines).
       
   In addition, the packages in "main"
       
     * must not require a package outside of "main" for compilation or
       execution (thus, the package may not declare a "Depends" or
       "Recommends" relationship on a non-main package),
     * must not be so buggy that we refuse to support them,
     * must meet all policy requirements presented in this manual.


Personally, I think it's a little bit much to expect volunteer
maintainers to be splitting source files.  I'll explain:

Gdk-imlib is a small package, so it's not a good example.  (plus Red
Hat has a libungif lib that might be useful)

But I am planning on packaging mico-2.0.8, which is a monster, and to
which this policy also applies.  It can be configured to generate
small supplementary libs for gtk, Qt, Xt, etc.  I'd like to generate
the Qt libs, in addition to the free ones.

Now, according to policy, in order to build a tiny supplementary
library for Qt that might only be 15k in size, I'm going to have to
build mico twice (and perform twice the maintenance).  That's a tall
order - mico takes over 2 hours and 150MB of memory/swap space to
build on my machines here.  Plus we'll waste twice as much archive
space for the source file.

And for what?

For mico, it's not like the free binary packages that go into main are
dependent on the non-free stuff in any big way.  If I only used one
source package, all it would mean to somebody that wanted to build
only those packages would have to do some quick edits to the
debian/rules files.

Of course, in reality, none of the ports is building only the "main"
part of the Debian - they are also building the "contrib" and
"non-free" parts..

In short - I'd rather not comply with the policy as it currently
stands.  I'll probably end up:

 a) ignoring the policy and living with an outstanding bug
 b) dropping the package altogether


Alternatively, I'd like to live by the book, and have the policy
amended slightly to reflect what most maintainers are currently doing:


 2.1.2 The main section

   All parts of every source and binary package in "main" must comply
   with the DFSG (Debian Free Software Guidelines).
       
   In addition, the binary packages in "main"
       
     * must be manually compilable using only packages from within
       "main".  It is permissible to have source packages which are
       also configured to produce binary packages that are not to
       be installed in "main", and which require tools from outside
       of "main" to do so.  However, it should be possible to
       easily edit the debian/rules makefile to not build those
       additional non-main binary packages.
     * must not require a package outside of "main" for execution
       (thus, the package may not declare a "Depends" or "Recommends"
       relationship on a non-main package)
     * must not be so buggy that we refuse to support them,
     * must meet all policy requirements presented in this manual.


Note, this removes the need to needlessly split source packages -
without affecting the DFSG freeness of the source code.

The only downside to this is that it becomes more difficult to rebuild
all the packages in main automatically without also building some
non-main packages (using some non-main tools).  Since nobody I know of
currently has this requirement, I think it's a pretty easy compromise
to make.

Comments?

Cheers,

 - Jim

Attachment: pgp4W9B5PcXtP.pgp
Description: PGP signature


Reply to: