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

Re: ITP vexim



Am Fri, 27 Jan 2006 11:37:42 +0000 schrieb Stephen Gran
<sgran@debian.org>:

> 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

That's what I actually did. Decide on the target and go on... 

> 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?

So if there is nothing to be done before an upgrade, there has to be no
action performed in prerm's target "upgrade", is it ok that way? I
really would like to get it working.

> 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.

Would it be a good "new version" if they did not care about the
manitainer scripts? Of course my scripts also need some work, still.
But I always thought, that they (knoppix, ubuntu...) took "our"
packages and modified them to fit their needs, not the other way.

While I'm in a quite good cooperation with the upstream author, I think
that new versions will be released not quite too often, and until
something changes in a larger amount, there will just be some
enhancements and minor bugfixes. For example in the php-section of the
package, but not in the sql layout or the basic behavior (system user,
mysql user, ...).
Would it be a good idea to outsource the database creation to a script
the user has to invoke manually? So maybe the maintainer script could
become a little bit smaller, and would not be possible to be
overwritten by accident. 

> 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. 

I am confident to get this piece of software packaged the right way
within some time, maybe within the next month. This will include,
maybe completely, redesign of my scripts. And your answer is "a kind of
medicine" for me at this point. Maybe i would have started to think,
that it is a "personal conflict", or worse, that this software is not
welcome in the Debian distribution.

If my questions and requests for help are really that much pain for
Marc, then I would kindly his pardon. It was NOT my intent to get
others doing my work, but sometimes there are so many things at the
same time, that cause confusion. In short: If my questions are a pain,
and you think still, that I dind't read the domcumentation and policy,
then try even not to answer, at least no every time "read the policy,
why didn't you". And I'll promise not to ask more often than really
needed.

many thanks
  Daniel

-- 
mfg
Daniel Knabl              http://www.tirolinux.net
PGP Fingerprint                   daniel@aio4u.com
A069 671B 39F2 E9B9 FB34  68BB 4BEC 1344 C8A4 3F0B

Attachment: signature.asc
Description: PGP signature


Reply to: