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

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

>>"Daniel" == Daniel Burrows <Daniel_Burrows@brown.edu> writes:

 Daniel>  1) User marks a package in Pretty Frontend, saying "I want
 Daniel>     to have this package installed from source in the
 Daniel>     future."

 Daniel>  2) Pretty Frontend cogitates and marks all of that package's
 Daniel>     dependencies and build-dependencies for installation
 Daniel>     (from source or not?  Not sure)

        Why not? In for a penny ....

 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, a pretty gui is not enough to
 handle all the ways things can be set. 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. 

 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.

 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).

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

 Pardon me, but do you know what it means to be TRULY ONE with your
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: