[tahoe-dev] [tahoe-lafs] #1220: build/install should be able to refrain from getting dependencies

[tahoe-lafs]

#1220: build/install should be able to refrain from getting dependencies
---------------------------+------------------------------------------------
     Reporter:  gdt        |       Owner:  gdt       
         Type:  defect     |      Status:  new       
     Priority:  major      |   Milestone:  undecided 
    Component:  packaging  |     Version:  1.8.0     
   Resolution:             |    Keywords:  setuptools
Launchpad Bug:             |  
---------------------------+------------------------------------------------

Comment (by gdt):

 You raise good points about unarticulated requirements; a lot of them are
 captured in "what 'make' is supposed to do".  So specifically, the build
 phase
  * should fail if any dependencies are missing.  C programs use autoconf,
 or autoconf/pkg-config, and fail at configure phase.  Or, they are old-
 school and do -lfoo and that fails at build time if libfoo is not
 installed.  You are probably right that some C programs do not reliably
 fail, but they should.
  * must not use the net at all, and use only files expressed in the
 "distinfo" manifest and downloaded during the fetch phase, and unpacked in
 the working directory in the extract phase.  If a file is needed it is
 listed in distinfo and make fetch gets it.  (Without this, offline
 building fails and GPL compliance is difficult - how do you find the list
 of sources that must be distributed with the resulting binary package?)
  * must set up install so that the list of created files is always the
 same

 An underlying goal is that building a package should have a deterministic
 outcome, with the same bits produced regardless of which dependencies or
 other programs were already installed.  This allows the use of the
 resulting binary packages on other systems.  If a program has an optional
 dependency foo, then the pkgsrc entry has to require foo (and thus depend
 on the foo package), or disable use of foo, or have a pkgsrc option to
 control it.  Having the built package be built differently depending on
 whether foo is present is considered a packaging bug (and perhaps an
 upstream bug, if there's no --disable-foo switch/method).

 It's also a goal to be able to 'make fetch-list|sh' on a net-connected
 machine and grab all distfiles but not build, and then to be able to build
 offline.

 I see that there are .pyc files installed, but not produced during build.
 This seems wrong, but not important or causing an actual problem, and it
 seems to be the python way.

 Basically, there's a huge difference in approach between large-scale
 package management systems and the various language-specific packaging
 systems.   I suspect debian/ubuntu and rpms are much more like pkgsrc than
 not in their requirements.  But, there seems not be a culture of bulk
 building all rpms in Linux; it seems the maintainers build them and upload
 them.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1220#comment:14>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage