This one time, at band camp, Daniel Knabl said:
> Am Fri, 27 Jan 2006 10:44:47 +0100 schrieb Marc Haber
> <mh+debian-mentors@zugschlus.de>:
>
> > How many times have you been pointed to Debian policy?
>
> Do you mean "after I already read it"? Then the answer is "too many
> times"...
>
> > And you are still asking questions that neatly show that you didn't
> > read it? And that also neatly show that you have never looked at other
> > packages?
>
> Maybe my question was confusing, that's possible.
> As I understand the policy, in details the chapters 6.6, 6.6 and 6.7,
> there have to be some actions performed on various targets of the files.
>
> The main target in postinst, when someone initially installs the
> software, is "configure", and in postrm, when someone purges it, it is
> "purge". For these two targets I found examples by looking at some
> other packages (phpmyadmin, album, ...) that do very similar things. And
> I implemented those actions to be performed also in my scripts.
>
> Now it seems, that I should also perform actions on some targets that
> do not get used in real installation process: who should upgrade the
> package, when there has never been a version of it before?
> Who should downgrade the package (to a non-existent version before)? I
> did some tests (installing, removing,purging ...) and there was no
> unexpected behavior.
Disclaimer: I have not looked at your packaging.
The standard way to do this sort of thing is look through the reference
for all the arguments your script can be called with, and handle them.
so something like:
case "$1" in
configure)
do_something
;;
targets|you|could|be|called|with)
;;
*)
echo "Unknown arg $1" >&2
exit 1
;;
esac
What it seems like you are missing is that Debian does not work in
isolation. Other distributions like Knoppix and Ubuntu and many others
reuse the work of Debian developers, and making your maintainer scripts
as robust as possible will help them as well as you. At the moment,
there are no Debian packaged versions of vexim, so why have an upgrade
target, right? Well, presumably you will add a new version at some
point, and then you'll have to handle the upgrade and downgrade targets.
Knoppix may in the meantime have added a new version before you get to
it, and forgot to check the maintainer scripts you wrote - bang, all the
upgrades on Knoppix fail.
Since it's not that hard to follow the recommendations of policy, and to
future proof your work, why not just do it? I agree, Marc is being a
little combative (I assume you've struck a nerve with him), but it does
sound from the outside like you've still some way to go on this.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature