[csw-maintainers] [Fwd: [csw-devel] SF.net SVN: gar:[3630] csw/mgar/gar/v2/gar.pkg.mk]
Dagobert Michelsen
dam at opencsw.org
Mon Mar 9 15:36:05 CET 2009
Hi,
Am 08.03.2009 um 17:26 schrieb Ben Walton:
> Excerpts from Philip Brown's message of Sun Mar 08 12:03:27 -0400
> 2009:
>> On Sun, Mar 08, 2009 at 11:54:58AM -0400, Ben Walton wrote:
>>> I submitted a patch for checkpkg a while back to solve this.
>>> Packages
>>> validated as a 'set' could reference other packages in the set as
>>> dependencies without checkpkg failing. I'm not sure what happened
>>> to it.
>>
>> erm... i think we had a discussion with dago, and we agreed to go in
>> [x direction], which was a little different than your original
>> patch, and
>> you said you would work on that direction...? :-)
>
> ...Which I did. I had wanted to allow for exclusions in checkpkg.
> This would have been used from GAR to tell checkpkg to ignore
> dependency foo since it was for an as yet unknown package. This would
> have helped in the situation where you're developing a new package
> that builds multiple packages with internal dependencies (lib, rt,
> etc).
>
> You didn't like that approach since it gives control to the maintainer
> and could be abused. While I disagreed with you on this[1], I did go
> back and put together a patch that let checkpkg save some state
> between package checks. This info allowed for a post-set validation
> of library and P package dependencies. This is the patch I referred
> to previously.
>
> -Ben
>
> [1] It's already possible for a maintainer to do whatever they want to
> checkpkg and/or GAR to circumvent anything they want...I did this to
> test my checkpkg changes. It still has to pass by the officially
> blessed checkpkg before release, so I didn't think there was anything
> wrong with it. If a maintainer chose to alter either of the above in
> such a way that bad packages slip through, the worst case scenario is
> that you get annoyed every time you kick back a broken package. In
> doesn't really matter, this is just my opinion. Having checkpkg do
> 'set' validation solves the same problem.
Yes. The usual reaction when checkpkg signals an error is
- look if it really is an error
- if not, just turn checkpkg off and submit the package anyway
Everything which checks more and bails out later is good.
Best regards
-- Dago
More information about the maintainers
mailing list