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

Re: installer for non-free packages in contrib

On Mon, 8 Sep 2003, Colin Watson wrote:
> OK. How does one create an installer package which correctly does the
> following:
>   * creates a Debian package for the thing it's installing

the installer contains a diff and dsc, downloads the orig source,
then builds a .deb

>   * installs that package in such a way that it's registered in dpkg's
>     database

do the install in the background when the dpkg DB area is unlocked

>   * doesn't rely on internal implementation details of dpkg such as
>     /var/lib/dpkg/status and /var/lib/dpkg/info/*.list files

should not be an issue given the above

>   * when the installer package is considered by dpkg as fully
>     configured, the package it's installing is also fully configured
>   * if some error happens when installing the created package, the
>     installer package will throw an error during configuration

I don't think these last two are possible without a dpkg daemon
(install from a queue instead of a list on the commandline), and even
then it would be necessary to be able to flag a package as using a
multi-stage install.

For the sake of argument lets assume the installer is configured and
didn't generate an error as long as it can get as far as downloading
the original source: you would not be able to configure anything
(during the same dpkg run) which depends on the package created by the
installer, and it would not be proper to flag the installer as
providing the package it creates (because the last two points can not
be met)...

> ? I think that's a minimal specification for a correct installer package
> which does its work by creating Debian packages; unless you think that
> it's better for the installer package to spit out a .deb somewhere which
> you then have to install separately, which seems to me like a step
> backwards in convenience.

...I guess I'd end up with a fetch-build-install instead of a proper
installer package --- a (half?) step backwards with respect to
Debian's dependency handling, but a step forward if the main objective
is to have "installer" installed stuff managed by the package handling

It would be clear that stuff installed by such a system is not a
part of Debian (because of the lack of dependency handling), and
migration into Debian would be easy when the license (or whatever is
keeping the software out of Debian) changes.

- Bruce

Reply to: