FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 05-17-2008, 05:51 AM
Allan McRae
 
Default Bumping a couple of patches

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".

2) http://www.archlinux.org/pipermail/pacman-dev/2008-April/011569.html
This is a pactest that flags one of the causes of the above issue. If
you try to remove the dependency chain pkg1 -> pkg2 -> pkg3 with "pacman
-Rs "pkg1 pk3", pacman fails. I realize this is adding a failing
pactest without solution, but it is probably something libalpm should be
able to handle.

Thanks,
Allan



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 08:29 AM
Nagy Gabor
 
Default Bumping a couple of patches

> 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...

>
> 2) http://www.archlinux.org/pipermail/pacman-dev/2008-April/011569.html
> This is a pactest that flags one of the causes of the above issue. If
> you try to remove the dependency chain pkg1 -> pkg2 -> pkg3 with "pacman
> -Rs "pkg1 pk3", pacman fails. I realize this is adding a failing
> pactest without solution, but it is probably something libalpm should be
> able to handle.

As you probably saw, I sent a patch for this in that thread.

> Thanks,
> Allan
>


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 09:59 AM
Allan McRae
 
Default Bumping a couple of patches

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.

Allan



_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 10:05 AM
Xavier
 
Default Bumping a couple of patches

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!);

Well, no one changed this behavior recently, so if we removed packages
before, we still do 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...
>

I don't understand, any chances you could try to explain that again?


In any cases, what Allan patch does is simply fixing this bug report
which had a pretty explicit title :
FS#10039 - [makepkg] Failure to remove deps should not return an error

So it seems safe to pull it. This doesn't prevent a future rework of
remove_deps function.

>> 2) http://www.archlinux.org/pipermail/pacman-dev/2008-April/011569.html
>> This is a pactest that flags one of the causes of the above issue. If
>> you try to remove the dependency chain pkg1 -> pkg2 -> pkg3 with "pacman
>> -Rs "pkg1 pk3", pacman fails. I realize this is adding a failing
>> pactest without solution, but it is probably something libalpm should be
>> able to handle.
>
> As you probably saw, I sent a patch for this in that thread.
>

Yes, I started looking at it a while ago and it seemed alright. Seems
like I have been disturbed by the infinite amount of other pacman issues
I reworked the git log, please check if it's alright.
My patch queue is available here :
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/working

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 11:11 AM
Nagy Gabor
 
Default Bumping a couple of patches

> > 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!);
>
> Well, no one changed this behavior recently, so if we removed packages
> before, we still do it now

I don't know how we did earlier, but I guess we remove it (I'm not on linux
machine now, just looked into gitweb), which is odd.

>
> > 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...
> >
>
> I don't understand, any chances you could try to explain that again?

Yes. A word missing :-/ (deletion). So you have an orphan package 'pkg'
installed on system. You like it, but you didn't change its install reason to
explicit with --asexplicit. You build something via makepkg which pulls a
package from sync, which needs 'pkg'. Then the final remove_deps steps will also
remove pkg due to -Rs, which you probably didn't want...
Vmiklos's method: he records the state of installed packages at the beginning of
makepkg then he removes the new packages at the end. Package upgrade can mess
things up a bit here too, since if you upgrade a package, that may have pulled
new dependencies, which is needed after makepkg run (no downgrade). But we have
a fancy -Ru option for this (and in general to force -R without harm) ;-P

Bye

----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 11:22 AM
Nagy Gabor
 
Default Bumping a couple of patches

> >> 2) http://www.archlinux.org/pipermail/pacman-dev/2008-April/011569.html
> >> This is a pactest that flags one of the causes of the above issue. If
> >> you try to remove the dependency chain pkg1 -> pkg2 -> pkg3 with
> "pacman
> >> -Rs "pkg1 pk3", pacman fails. I realize this is adding a failing
> >> pactest without solution, but it is probably something libalpm should be
> >> able to handle.
> >
> > As you probably saw, I sent a patch for this in that thread.
> >
>
> Yes, I started looking at it a while ago and it seemed alright. Seems
> like I have been disturbed by the infinite amount of other pacman issues
> I reworked the git log, please check if it's alright.
> My patch queue is available here :
>
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/working
>

Seems allright.

Bye


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 06:23 PM
Xavier
 
Default Bumping a couple of patches

Nagy Gabor wrote:
> Yes. A word missing :-/ (deletion). So you have an orphan package 'pkg'
> installed on system. You like it, but you didn't change its install reason to
> explicit with --asexplicit. You build something via makepkg which pulls a
> package from sync, which needs 'pkg'. Then the final remove_deps steps will also
> remove pkg due to -Rs, which you probably didn't want...

Ok so now, that's clearer, but it's not my understanding of what makepkg
does. As far as I can tell, makepkg only pulls the required deps, with
the help of pacman -T. So that's the deplist.
Since in your example, 'pkg' was already installed, it won't be in that
list, and so makepkg won't try to install it, and won't try to remove it
at the end.
I could be wrong though, and I didn't check if it's really the case.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-17-2008, 07:37 PM
"Aaron Griffin"
 
Default Bumping a couple of patches

On Sat, May 17, 2008 at 4:59 AM, Allan McRae <mcrae_allan@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

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 06:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org