Re: Silly Packaging Problem
On Thu August 10 2006 16:20, martin f krafft wrote:
> also sprach Bruce Sass <email@example.com> [2006.08.10.2237 +0100]:
> > No point setting oneself up for bugs if it is not necessary.
> > The script wouldn't determine anything, it would simply append
> > paths to the package's list of paths. The Maintainer would need to
> > call the script "right after file generation succeeds", or perhaps
> > with a list of files just generated, or as part of an install if
> > packageless files are known to exist.
> Ah, now I understand. Yeah, sounds like a good idea. After all,
> a file may or may not be created, something not known during build
> So when can we expect patches from you? ;)
Seems like the kind of thing which should be done by a DD or
firstname.lastname@example.org (especially since it relies on dpkg's behaviour and mucks
with their DB).
I will be so bold as to suggest...
Synopsis: update-package [options] <command> <package>
update-package [options] --add-files=<paths> <package>
update-package [options] --remove-files=<paths> <package>
update-package [options] --size=<absolute | [+|-]increment> <package>
update-package [options] --field=<label>::<new-value> <package>
--*-files modifies the indicated package's list of files
--size changes or modifies a package's Installed-Size: field
--field changes the value of an arbitrary field in a package's DB entry
"files" and "size" accommodate the desire to include generated or
packageless files and their size (if knowable) in the dpkg DB.
"field" can be used by an admin to override a package's meta-information
so it better reflects local changes in those cases where building a new
package is overkill. e.g.: a local Maintainer: for a pkg with config
changes only, new Depends: and/or no need for an equivs package to hack
around a temporary problem or situation. Potentially a very nasty
[what can I say, it is not that unusual for me
to "editor /var/lib/dpkg/status" to work around a packaging problem, or
dpkg/info/<package>.list then dpkg-repack and install somewhere else...
but maybe I'm "evil" or enshrining the ability in a utility would send
the wrong message... perhaps another reason for a DD or team@dpkg to
provide the functionality <shrug>]
- the usual useful stuff (help, version, verbosity, logging)
- maybe an admin controlled "off" switch, just in case having a local DB
which differs from the packaged one is a problem (implies a config file
- automatic Installed-Size: updating, not always useful or accurate,
maybe best left as a invocation only option because only the Maintainer
knows for sure
/etc/update-package and/or $HOME/.update-package
..., write some more if necessary to clarify something, and be an early
adopter/test-dummy though. :-)