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

epochs, circular dependancies, and other miscellany



I'm looking for some help on the dpkg/apt-based centralized
configuration system I'm working on.  Note that this is intended for
use at the site I administer, and while I'd be pleased if it proved
useful to others, it isn't intended to be a general solution.  So
please don't flame me for doing things in a way that's non-Debian.

First an overview of how I intend it to work:

Clients are updated by running apt-get dselect-upgrade.  Since I want to
be able to do this noninteractively, I have to get around both postinst
scripts that interact with the user, and dpkg's handling of conffiles.
I need this now, not when potato is ready, so I have to roll my own
approach to noninteractivity.

My current plan is to keep a local apt repository for the machines using
this system.  In it I will have modified versions of all packages with
conffiles or postinsts; those which don't have either will exist in their
original slink versions.  To modify package A:

- extract the files listed in its conffiles and postinst (possibly also
  cron.* files, if they're not always conffiles?)
- rebuild it without these files, and in addition give it a new version
  number, probably the same as before with a new epoch, and a 
  Depends: local-config-base-A, local-config-A local-config-A
- put the extracted files in a new package called local-config-base-A
  with Provides: local-config-A; give it an upstream version number
  corresponding to that of the original A, and a Debian revision number
  of 0 initially; don't create conffiles entries for any files, even if
  they had them in the original A
- if the postinst (now belonging to local-config-base-A) is potentially
  interactive I manually change that
- now if I like I can of course create other local-config-*-A packages 
  that provide local-config-A and conflict with other providers

The issues I'm currently trying to deal with include:  

* epochs not being recognized.  A concrete example is
provided by a test case I did with cvs; for brevity we'll call it cvs_V
instead of cvs_1.10.7-1.99.slink.y2k.1.  I broke it into two packages,
cvs_5:V and local-config-base-cvs_V-0.  When I did a 
  dpkg --purge cvs; apt-get update; apt-get install cvs
it would retrieve whichever cvs (cvs_V or cvs_5:V) was in the ftp
repository listed first in sources.list.  Moreover, the retrieved file
doesn't have the epoch prefix.  Clearly I've misunderstood the
functionning of epochs or apt-get; can someone enlighten me?

* circular dependancies.  Continuing with the prior example, I want cvs
to depend on local-config-cvs so that the package doesn't get installed
without config files. On the other hand, since the postinst is now in
local-config-cvs instead of cvs, local-config-cvs should depend on cvs
so that the postinst is able to use the contents of cvs.  Since there's
no postinst to be done for cvs itself now, really what I'd like is to be
able to have this circular dependancy and for dpkg not to complain about
each package depending on the other's being configured.  

I'm currently just doing the cvs depends: local-config-cvs, since I'm
not anticipating the local-config files being installed by themselves.
Naturally this isn't ideal though - suggestions appreciated.

* Size and Installed-Size:  any tips on how to easily generate these
control fields for my split packages?


Reply to: