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

Re: Smarter dpkg/apt rather than new distro ?

On Wed, 2004-02-25 at 06:37, Geoff Brimhall wrote:
> Been reading through the goals of emdebian, and the
> thought popped up that rather than create a whole new
> distro, make a smarter dpkg/apt which would strip the
> unwanted parts out of a *.deb, or divert them to the
> compact flash storage for use when needed.
> At intimate.handhelds.org, many,many packages from
> debian-arm can be used. Version 1.0.1 of opie is in
> debian unstable. Why not use what's there, but make
> the installer more intelligent - remove unwanted
> documentation/packaging info so it is conformant to
> ipkg.

There are 3 main reasons why we cant do this at the moment, even though
it would be really nice if we could.

1. dpkg/apt cant on their own strip out documentation as it is not
labelled as such. You can however do it if packages use debhelper say.
Fixing dpkg so that it knows what docs are itself would be worthwhile
(rpm can do this and you can install with --nodocs). It is of course
against Debian policy not to have docs so this might take some
persuading, but it is potentially worthwhile (but see 3).

2. Some packages just require/expect/provide a lot in a way that is not
modular. In some cases this is just a matter of making packages more
finegrained (eg the example of gstreamer which can use large numbers of
libraries, but as it has a plugin structure for these you can just spilt
it as gstreamer-libmpeg2 gstreamer-ffmpeg plus a base package), in other
cases people are just lazy (adduser is a perl script). Mostly this is a
matter of social engineering on the package maintainers, but they wont
do it unless you have got something you can show. Also we really dont
know how much needs changing in this way, and how much there are other
workarounds (eg providing tinylogin's adduser as a replacement adduser
package would fix this case).

3. Build dependencies. This is the real problem. Even if you split a
package into nice subpackages or alternatives, the build process is
monolithic, and there is therefore a requirement that you can build all
of them. This makes building from source almost impossible, as there are
thousands of dependencies. The long term solution is probably to change
dpkg to allow variant packages to have their own build dependencies and
to allow builds of just single variant packages not all of them. But we
are not sure we know the answer until we have tried several things out.


Reply to: