pkg_add errors

[Dominic Fandrey]

Boris Samorodov wrote:
> Hello Dominic, List,
> 
> Thanks for your work, much appreciated.

You're welcome.

> Dominic Fandrey <kamikaze at bsdforen.de> writes:
> 
>> I need something similar for the incomplete package problem.
>> Should pkg_upgrade create a summary of apparently broken packages
>> that have been installed?
> 
> I would go with this option since one can use not only official
> packages but home made ones (and without much testing).

I suppose. So this goes into the list of feature requests.

>> Should it bail out (and break with every
>> package that has a broken plist)?
> 
> That imho would be a little bit draconian.

Pav Lucistnik suggested cups-base was to blame. Well, I just read
/usr/ports/UPDATING and this is definitely one of the things
that cannot be dealt with automatically.

> BTW, current behaviour of "pkg_upgrade -F" to stop at the first package
> that can't be downloaded is the same. Can this behaviour be changed
> to proceeding but printing out the list of not downloaded packages
> at the end? Or at least can you create an option for such behaviour?
> 
>> Should it perform library checks
> 
> That may be done via command line option.
> 
>> and try to auto fix them?
> 
> That task seems to be very hard to achieve.

I've actually put some thought on this. It's been on the list of 
planned features for a long time. I'm pretty certain, I can deal
with a large majority of library problems without human interaction.

What irks me about it is that the sequence of actions would be
broken by this. Features like fetching in advance and performing
updates later would break. And all these problems could be
avoided if library changes always resulted in a version bump of
all dependencies.

A path that has been followed more often recently, but still cannot
be relied on.

> 
>> My preference would be to rely on 'pkg_info -g', but that would
>> require all committers to run extensive checks before committing
>> changes to the ports tree. Miwi has always done this and more than
>> once revealed PLIST problems of my ports to me. But I wonder whether
>> it is really sensible to ask committers to test everything on a
>> Tinderbox (preferably on several platforms) before committing
>> changes to the ports tree.
> 
> Hm, ports with broken PLISTS are, well, broken. And should be fixed
> or marked BROKEN. I was sure that the FreeBSD packaging cluster does
> not produce packages with broken plists (i.e. the package is not
> created). Is that wrong?

I think so. After all the Pointyhead packages are built from the
same ports tree as the one everyone else uses. And that has a couple
of persistently broken plists, not many, but some.

> 
> 
> WBR