[pacman-dev] Bumping a couple of patches

[Aaron Griffin]

On Sat, May 17, 2008 at 4:59 AM, Allan McRae <mcrae_allan at hotmail.com> wrote:
> Nagy Gabor wrote:
>>> Hi,
>>>
>>> I am just bumping a couple of patches because I have been bitten by this
>>> issue again, twice in the last few days...
>>>
>>> 1) http://www.archlinux.org/pipermail/pacman-dev/2008-April/011562.html
>>> This allows makepkg to catch an error from when pacman is unable to
>>> remove installed dependencies after makepkg successfully builds a
>>> package and instead prints warning.  There was a discussion about
>>> whether this should print a list of packages that were installed as
>>> dependencies, but I still feel that this is covered by using "pacman
>>> -Qtd" and "tail /var/log/pacman.log".
>>>
>>
>> I don't see any clean solution for this. My main problem: it is impossible to
>> restore the "before makepkg" state. If we upgraded a package, we cannot
>> downgrade (btw. I hope we don't remove it now!); if we have an orphan package
>> and we installed package which needs it, with -Rs we does an unwanted orphan.
>> vmiklos's method seems safer to me here...
>>
>
> What do you mean upgrade package? The dependencies are installed with
> "pacman -S <deplist>".  The two problems I see are the chained
> dependencies (as below) and provisions.  The first, if not the second,
> should probably be fixed at the source.   makepkg is not a tool to keep
> your install clean.  Sure there are edge cases where this might not be
> fixable in libalpm, but all the information is there for the user to
> investigate the problem and clean up their system themselves.
>
> Also, removing extra orphan packages is not an issue as far as I'm
> concerned.  It is an orphan, so must be a left over from something, and
> cleaning it is a good thing.
>
> Anyway, this patch fixes a problem.  makepkg will no longer exit with an
> error when removing installed deps fails and lets the user know whats
> happened.  If someone want to try improving the removal of installed
> deps, it can be added later.

For the record, this was my bug report. I noticed it when using the
chroot tools, which check the return status from makepkg. In essence,
the scripts only move packages and things if makepkg succeeds.

I have since changed the chroot scripts to always check for the
existence of a pkg.tar.gz after build, regardless out output, but this
is still an iffy case: what if tar fails in the middle of making the
file, and doesn't delete the goofed file? makepkg would probably
notice. So the return status is nice to know, and it should really
only be if "make package" makes a package or not