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

Re: More-automated from-source installation of Debian packages

On Tue, Feb 08, 2000 at 12:23:28AM -0600, Manoj Srivastava was heard to say:
>  Daniel>  3) Pretty Frontend downloads all files needed: the package source,
>  Daniel>    packages for its various dependencies.
>  Daniel>  4) Pretty Frontend presents the user with a list of
>  Daniel>     commonly-used compile options, asking him/her to select
>  Daniel>     the desired set from it.  (there is probably an
>  Daniel>     "advanced" button somewhere which allows environment
>  Daniel>     variables and/or configure arguments to be manually
>  Daniel>     typed)
>         Why not just ./debian/rules build? If people are knowledgeable
>  enough to want to tinker with options,

  If a simple listing of common options can be generated, then anyone will be
able to tinker with options.

>  a pretty gui is not enough to handle all the ways things can be set.

  Absolutely true.  However, I rarely use all the way things can be set.  Do
you?  For people who need to do more than is possible via the GUI,
debian/rules build will still be an option.

>  Allow for a downlod and unpack stage, at which point one can tineker with
> build, and then a build stage, which calls ./debian/rules build. 

  At least one reason is that ./debian/rules build has to be re-run by hand
each time the package is upgraded, with every single option supplied (some
passed as configure args, some as environment variables, some as Makefile
variables..)  Often this involves editing the build scripts, and if you don't
make every modification exactly the same way in each package version you'll lose
one or more features and have to start over again.  A diff might help, but if
the package maintainer moves stuff around you're back to square one.

>  Daniel>  5) Pretty Frontend installs all (build-)dependencies of the
>  Daniel>     package. (note that this might include the package
>  Daniel>     itself; think gcc)
>         Generalizing this is a bad idea. Obviously, certain packages
>  in build essentials ahve to be excempt )go ahead, build make without
>  haing it preinstalled) 
>          One of the reasons for recompiling from known source is
>  security and compatibility, and general circular dependencies in
>  build depends should be strongly deprecated.

  Probably either the frontend or Debian can determine the rules about this.

>  Daniel>  6) Pretty Frontend unpacks the package source (say,
>  Daniel>     under /usr/src/debian-build) and proceeds to compile it
>  Daniel>     with the options the user selected.
>         Again, I thik we should use ./debian/rules build.
>         That should bring in the most common options already tuned for
>  each package. Een this is hard for an automated tool to do
>  (are you going to edit configure.in? or local.m4? or local.conf?
>  These are just some places where options are set, and edited in place
>  by the maintianer).

  I may not have been clear enough; the idea is that the maintainer (who
theoretically knows the package) provides a list of common options and writes
scripts to handle them.  For most packages this is simply a matter of passing
different arguments to configure, or maybe defining stuff on the make command
line.  If the maintainer doesn't define anything, the worst that'll happen is
that we're back to the current situation.  This might be putting too much burden
on the maintainers, which is the main objection I forgot to mention in my
earlier mail -- more than, say, debconf, as the number of packages with
useful compile options is probably higher than the number that need to accept
input in the postinst.  OTOH, these lists of options should be entirely
optional, and could probably be contributed by skilled users as well as

  Also, for configure scripts, this could probably be somewhat automated by
extracting the --with and --enable arguments, either by parsing the m4 files
for AC_ARG_WITH and friends (eek!) or snarfing the output of --help.  eg,
fetchmail's configure says:

--enable and --with options recognized:
  --disable-nls           do not use Native Language Support
  --with-included-gettext use the GNU gettext library included here
  --with-catgets          use catgets functions if available
  --enable-POP2           compile in POP2 protocol support (obsolete)
  --disable-POP3          don't compile in POP3 protocol support
  --disable-IMAP          don't compile in IMAP protocol support
  --disable-ETRN          don't compile in ETRN protocol support
  --enable-RPA            compile in RPA protocol support
  --enable-NTLM           compile in NTLM authentication support
  --enable-SDPS           compile in SDPS protocol support
  --enable-opie           support OTP through the OPIE library
  --enable-inet6          support IPv6 (requires the inet6-apps library)
  --enable-netsec         support network security (requires inet6-apps library)
  --with-kerberos5=DIR    point fetchmail compilation at a Kerberos 5 directory
  --with-ssl=[DIR]        enable SSL support using libraries in DIR
  --with-kerberos=DIR     point fetchmail compilation at a Kerberos directory
  --with-socks[=DIR]      add built-in SOCKS firewall access
  --with-hesiod=DIR       point fetchmail compilation at a HESIOD directory
  --with-gssapi[=DIR]     compile in GSSAPI support using libraries in DIR

  If an autoconf-using program hardcodes settings into configure.in or
aclocal.m4 it could possibly be considered a bug.  A maso^H^H^H^Hdetermined
maintainer could also write sed scripts to switch the options around at compile
time, although I agree that this is a...er...suboptimal way to do things.

  Some build systems (eg: local.conf, Makefile.{rules,defines}) are a lot harder
to automate.  So not every package in Debian can implement this easily.  I
maintain that a significant percentage would benefit.

  'course, until I have a specific scheme hashed out to do this this is really
a lot of hot air.

>         Allowing pretty gui to set common options is a lot harder than
>  you think.

  Well, I didn't say it should try to set it in the general case, only when a
human (the maintainer) has given hints about what is there and how to apply
the settings.  Some packages will be particularly intractable -- xfree comes
to mind -- but I think this is doable.


Reply to: