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

Re: Silly Packaging Problem

On Thu August 10 2006 16:20, martin f krafft wrote:
> also sprach Bruce Sass <bmsass@shaw.ca> [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
> time...
> So when can we expect patches from you? ;)

Seems like the kind of thing which should be done by a DD or 
team@dpkg.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. :-)

- Bruce

Reply to: