[Piuparts-devel] Bug#595119: piuparts: modular way to add new tests?

[Scott Schaefer]

On 05/31/2011 03:31 AM, Timo Juhani Lindfors wrote:
> Hi,
>
> Scott Schaefer<saschaefer at neurodiverse.org>  writes:
>    
>>  From reading your report and your patch, I believe you can achieve
>> this with the "custom scripting" interface
>> (/usr/share/doc/piuparts/README.html or
>> http://piuparts.debian.org/doc/README.html#_custom_scripts_with_piuparts).
>> While perhaps not ideal, this interface provides a 'modular way to add
>> new tests'.
>>      
> Looks good indeed but is this only for my private tests? How do I get my
> tests to run on piuparts.debian.org?
>
>    
Hm ... Well, that is a very good question.  And, I understand what you 
are trying to do is outside the scope of what can be expected of 
"private tests".  Unfortunately, I am afraid your question raises a 
large number of issues, well beyond a scope I feel qualified to comment 
on (other than to note they exist) ...

Given what I have read, and reviewing list of wishlist bugs, I am 
reasonably certain a "framework for securely executing plugins" will be 
a big part of any future discussion re "piuparts 2.0".

Until then, the only alternatives I see are to revise/include your patch 
and/or to provide some way to provide for "package-specific" scriptdir.  
The latter is extremely problematic in master/slave setup, since the 
scripts would have to either exist at the slave, or some means of 
copying/exchanging in the protocol would need to be be introduced.


>> In order to verify I am understanding ...
>>
>> You seemingly need a way to determine if<pattern>  is anywhere in the
>> "list of" Depends:; thus, your patch causes this to be built even in
>> absence of --warn-on-others.  You then want to be able to test
>> (ideally, via regexp ?) for presence of>=1 patterns in this set, and
>> conditionally run your additional test(s) based on presence/absence of
>> these patterns.
>>      
> For example yes. The debian policy says that such a depends needs to
> exist in a package that ships emacs addon packages that do
> byte-compilation.
>
>    
>> While I have not attempted to produce set of shell scripts that
>> provides this functionality, I believe there is no fundamental
>> constraint in the interface that would preclude doing so.   Am I
>> misunderstanding; i.e. is there some way the current interface does
>> fails to address your needs ?
>>      
> I didn't notice this custom scripting interface at all at that time.
>
>    
>> Finally, note your patch appears to unconditionally install and purge
>> emacs if you run the test; this is likely not correct, since emacs may
>> have either already been installed (dist-upgrade), or been installed
>> by install_packages, so that this may then lead to subsequent error(s)
>> during purge.
>>      
> True.
>
> -Timo
>    

I am willing to "come back" to this bug at later date.  However, I don't 
expect that to happen until I or someone fixes the 3-4 important/normal 
bugs outstanding.