Hi Stefano,
lots of cool ideas.
On 2008-07-24 10:55:23.00 Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:
On Mon, Jul 21, 2008 at 07:21:51PM +0200, Thomas Viehmann wrote:
> first, thanks for the patch! We really should get this
implemented.
Nice to ear :)
> > post_upload_hook_dir = /etc/dput/post-upload.d/
> > pre_upload_hook_dir = /etc/dput/pre-upload.d/
> I would prefer this to be {pre,post}_upload_hook_dirs and take a
list
> (comma or white space separated) as argument.
ACK, noted.
> Also, it should default to /usr/share/dput/{pre,post}-upload.d/.
Most of
> the hook scripts should not be config files and almost none
system-wide
> configuration files. I'd be open to adding something under
~/.dput to
> the default, though.
No objection, as long as I would like to be directories where other
packages can drop stuff to plug into dput hooks without the need of
manual configuration (your proposal fulfill that need). Still, out
of
curiosity, would you be against having, say,
/usr/share/some/thing/:/etc/some/thing/ ? The latter can be empty by
default, but would enable people to override system-wide scripts
having
to fiddle with just one file (the script itself, to be written from
scratch) instead of two (the script _and_ the configuration file).
If you prefer that, I'm cool with it. The reason I'm not liking
that is because my experience with dput configuration is that it's
either upstream configuration or user configuration, and usually
not system configuration. As such, I'd just drop it to prevent abuse.
If you say that it's terribly cool to have, then let's have it by
default.
Note that regardless of our default setting, any user could override
the setting to include any paths he likes.
(I like the colon as separator.)
> Having multiple dirs makes ordering more difficult (scanning them
first,
> with later hook_dirs overriding earlier ones for the same
filename and
> then executing in alphabetical order of basenames might be nice),
but
Noted as well, unfortunately this defeat using run-parts (unless you
know how to invoke it providing a script list instead of a
directory),
but replicating its behaviour for our needs it's easy.
Yeah. But then overriding system defaults should be possible from user
configuration without dropping the whole system hook dir path. This
seems
worth doing a glob + merge/sort + execute manually in python.
> also gives the user the opportunity to override specific hook
scripts or
> mix user and stock hook scripts in his preferred order of
execution.
> OTOH, maybe that's overdesigned.
Override is fine, especially with the failure semantics which by
default
stop the upload (BTW I think we should add a --force like switch to
bypass this check), this way users can shield themselves from
misbehaving hooks. Regarding changing the execution order, yeah,
sounds
like overdesign to me.
Well, the particular execution order isn't important, to me I'd just
like
to have it fixed by sorting everything by basename.
> Finally, we'd want to make sure how to pass parameters flexibly
to the
> hook scripts. Maybe the most natural thing is to set environment
> variables for the spawned scripts?
I gave a thought about it when first writing the patch and I came
to the
same conclusion.
> These are the two points I'd like to see addressed (or for the
latter
> question at least thought about, if we go for environment, this
can be
> added later) in a patch before putting it into Debian. Apologies
if I
> haven't been clear enough on them on IRC. I'm removing the tag
patch as
> suggested by the developer reference just in case anyone gets
ideas
> about the patch being ready to be NMUed or put in other places
where it
> is then expected to be merged.
No problem about that, if you want a better patch (i.e.
implementing the
above feature) you are totally right in removing the "patch" tag.
I'll
give a try to write a better patch, though I'm not sure it will
happen
before DebConf. If it does not I'll add it as a TODO item for my
DebCamp
days.
Cool. I'd really appreciate with that. Please do coordinate with
Giridhar, anything he OKs works for me.
I've a bonus feature request to be mentioned though. For my initial
need, which is running edos-debcheck on the packages being uploaded
(which, BTW, is also something other people are using for a priori
QA
needs in, e.g., Emdebian) the hook system we are designing is
suboptimal. In fact, what I need is hooks to be executed on all the
packages being uploaded rather than on a package-by-package basis.
What
do you think about adding extra hooks, isomorphic to the one
discussed
above, but to be run once and for all the packages being uploaded?
Ugh. I don't know that it's presently possible to do pass a lot of
information to these hook scripts. My requirement would be that the
processing of packages is still strictly serial (i.e. no partial
parsing, checking, etc. of everything before the packages are
processed one by one). If a startup hook that sees just the command
line works for you, that's fine by me. Saving parsing of .changes is
not an argument to me here.
Kind regards
T.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
