Arch Linux

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

cleaning orphans not explicitly installed...

I see that reverse dependencies are already tracked in the package database, and with some modifications packages installed explicitly by the user could be flagged. This could fix the following situation (I'm doing this on my own machine as an experiment, but the names have been changed to protect the innocent):

A KDE user hears how great Gnome 2.6 is, and decides to give it a shot so he installs gnome-desktop which also installs the following packages

$ sudo pacman -S gnome-desktop

Targets: libglade-2.4.0-1 docbook-xml-4.1.2-2 scrollkeeper-0.3.14-1
         gnome-common-2.4.0-3 libgnomecanvas-2.6.1.1-1 orbit2-2.10.3-1
         libbonobo-2.6.2-2 gconf-2.6.3-1 shared-mime-info-0.14-1
         gnome-mime-data-2.4.1-3 gnome-vfs-2.6.1.1-1 libgnome-2.6.1.1-1
         libbonoboui-2.6.1-1 gnome-keyring-0.2.1-1 libgnomeui-2.6.1.1-1
         startup-notification-0.7-1 gnome-desktop-2.6.2-1

Proceed with upgrade? [Y/n]

so he hits enter and comes back in a few minutes and plays w/ Gnome for about an hour, and decides it's not for him... so he does...

$ sudo pacman -R gnome-desktop
removing gnome-desktop... done.

okay, that was easy... the problem is though that the other deps that were installed are still on the system!

Now there is pacman -Rs gnome-desktop, but on my system that removes samba because removing it wouldn't break any other packages (other than samba).

$ sudo pacman -Rs gnome-desktop

Targets: gnome-desktop libgnomeui startup-notification libbonoboui libgnome
          gnome-keyring libgnomecanvas gnome-vfs gconf libglade libbonobo samba
          gnome-mime-data orbit2 gnome-common shared-mime-info scrollkeeper
          docbook-xml

Do you want to remove these packages? [Y/n]

I don't want to remove samba, that was installed explicitly earlier.

There is also pacman -Qe which will give you a list of 'orphaned' packages (packages w/ no reverse deps). Try this on your own system to see what it looks like (you do have arch installed, right?).

Now say that when I installed gnome-desktop it was flagged as explicitly installed, and the deps were not. Also when I installed samba, it would have been marked as explicitly installed. So when I remove gnome-desktop, all packages that are orphans, and not explicitly installed could also be removed, but samba would not because it's flagged as being explicitly installed.

This would also work for situations where both packages A and B depend on package C. I install package A which installs C as a dep, and then I install package B. I then remove package A, but since C is not an orphan it is not removed.

This may already be in development, but if it's not I'd like to volunteer to get this going, and for that matter anything else that needs to be done.

About Myself:
I just started using Arch, and really like what I see in it's philosophy, design and community. I was actually thinking about starting my own distribution, but then spent some time on distrowatch, and found Arch. I am a Junior at Oregon Institute of Technology (don't judge them on their website), and am looking for something to contribute to the OSS community.

Dusty

Schwag Merchant

From: Medicine Hat, Alberta, Canada

Registered: 2004-01-18

Posts: 5,986

Website

Re: cleaning orphans not explicitly installed...

Now say that when I installed gnome-desktop it was flagged as explicitly installed, and the deps were not. Also when I installed samba, it would have been marked as explicitly installed.

One question, What if you installed gnome-desktop first, then you decided you needed samba but since it was already installed you wouldn't have to install it... then things break (anyway) when you remove gnome-desktop.

This may already be in development, but if it's not I'd like to volunteer to get this going, and for that matter anything else that needs to be done.

I do know that Judd has done some research and/or work into this area, and that the functionality of the pacman -Qe option is not necessarily concrete. I don't know how far the plans have come though.

If you would like to start on a patch for this, go ahead. There aren't any gauruntees that it will accepted (nothing saying won't be either).

Dusty

---

** Arch Linux Apparel and more ** Arch Linux stickers, laptop bags, jewelery ** I wrote a book on Python 3 ** and one on mental health **

Offline

#3 2004-08-12 16:51:45

lanrat

Member

From: Poland

Registered: 2003-10-28

Posts: 1,274

Re: cleaning orphans not explicitly installed...

I'm to tired today to really think about it logically :-) but there is also /var/log/pacman.log which will tell you what was installed after what and when ;-) (though having something automatic would be nice too).

Offline

#4 2004-08-12 18:58:46

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

One question, What if you installed gnome-desktop first, then you decided you needed samba but since it was already installed you wouldn't have to install it... then things break (anyway) when you remove gnome-desktop.

Good point...
There could be a way to mark samba as explicitly installed post-installation. I'm not sure if this is a good idea, but there is the option of having a flag in the package file itself to say weather it is more of a dep (library or something) or a useful package (samba, etc). I think that would cause more problems than anything.

I'm to tired today to really think about it logically Smile but there is also /var/log/pacman.log which will tell you what was installed after what and when Wink (though having something automatic would be nice too).

Yes, but that logs all installs, including deps, and doesn't diferentiate between deps and explicitly installed packages. Thanks for pointint it out though.

by the way just to be clear, this isn't an origional idea... it is implemented in Debian very well, and sort of in Gentoo (and maybe some others I don't know about)

~Jake B

Offline

#5 2004-08-12 19:45:52

lanrat

Member

From: Poland

Registered: 2003-10-28

Posts: 1,274

Re: cleaning orphans not explicitly installed...

Yes, but that logs all installs, including deps, and doesn't diferentiate between deps and explicitly installed packages. Thanks for pointint it out though.

True. But It would be easier (I think) to add an option to pacman to write another flag next to date in the log file (something like: D - dependency install, E - explicit install). Since the log is already there and all information is available to pacman during install....

Also if you analyze it in the chronologial order then you can see for example if samba was installed as a dependency or explicitly by a user. This of course is not 100% bulletproof because dependencies change in time, some people do installs/removals with -Sd/Rd options, etc, etc. Maybe if pacman would also save in the log name of the package that requested other package to be installed as a dependency - this could help. In other words pacman log should consit of every detailed command issued by a user.

by the way just to be clear, this isn't an origional idea... it is implemented in Debian very well, and sort of in Gentoo (and maybe some others I don't know about)

~Jake B

IIRC it's not that original here too. If you search the forums you will find some ideas and even applications/scripts that do (more or less) what you want.

Offline

#6 2004-08-12 19:59:42

i3839

Member

Registered: 2004-02-04

Posts: 1,185

Re: cleaning orphans not explicitly installed...

An alternative would be to do more or less the same as when installing a group: Instead of asking "Proceed with upgrade?" ask "Remove all the above packages?" and if the user says no then prompt for each package seperate.

Offline

#7 2004-08-12 20:22:46

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

True. But It would be easier (I think) to add an option to pacman to write another flag next to date in the log file (something like: D - dependency install, E - explicit install). Since the log is already there and all information is available to pacman during install....

ahh, I see your point. It might not be so easy though because it would have to watch out for removals, and reinstalls -- though simply looking for the last install would probably work in most cases. IMHO It would probably be cleaner to add the flag to the package database, after all it seems a log is for seeing what has been done in the past, and the database is for keeping data about the packages. Lots of stuff could have been stored in and calculated from the log file.  Would there be a lot of resistance to adding this to the database? Arch isn't at version 1 yet, so maybe it wouldn't be such a big deal to change the database slightly, especially if it didn't break any current systems.

To keep backwards compatability existing packages could be flagged as installed explicitly by default. This would prevent wanted packages from being treated as orphans, but would also prevent orphans from being treated as orphans. However this would make things continue to work until a fresh install, or one could go thorugh and manually mark the undesired packages as deps.

edit: I found a simmilar proposal here:  http://bbs.archlinux.org/viewtopic.php?p=11730#11730

Offline

#8 2004-08-12 20:46:58

Xentac

Forum Fellow

From: Victoria, BC

Registered: 2003-01-17

Posts: 1,797

Website

Re: cleaning orphans not explicitly installed...

This is something that has been mentioned and is on the todo list.  Feel free to co-ordinate with Judd about it (read: send him an email).

Personally, I agree that adding a flag to the database is the best bet and also not a problem (we've done it numerous times without affecting backwards compatibility).  Log files get rotated, can't grow forever, and aren't reliable.

---

I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

#9 2004-08-13 07:57:43

kpiche

Forum Fellow

From: Ottawa, ON, Canada

Registered: 2004-03-30

Posts: 246

Website

Re: cleaning orphans not explicitly installed...

Some ideas:

1.  Perhaps a tag can be added to all packages that indicates whether the package is "standalone" or a supporting "library".  Samba can be utilized on its own but could be used by another program to browse a network.  Whereas libpng is not useful by itself.

2.  Implement a notion of changesets (like source versioning) or transactions.  Installing a package and its deps can be tagged with a new local group name.  Then the set of packages could be removed by removing the local group.

Offline

#10 2004-08-13 15:17:28

Takaitra

Member

From: Minnesota

Registered: 2004-05-24

Posts: 10

Re: cleaning orphans not explicitly installed...

jbNet, I searched searched the forums looking for the exact functionality you described and found your thread. The 'pacman -Qe' gave me a list of packages to look at removing but it's no 'emerge depclean' as I could do in Gentoo. It would be great to have the same list as given by 'pacman -Qe' without the explicitly installed packages.

I just started using Arch, and really like what I see in it's philosophy, design and community. I was actually thinking about starting my own distribution, but then spent some time on distrowatch, and found Arch. I am a Junior at Oregon Institute of Technology (don't judge them on their website), and am looking for something to contribute to the OSS community.

I'm also a new user of Arch and am a junior at the University of St. Thomas. If you start work on this, I'd like to help out.

Offline

#11 2004-08-13 15:47:16

Dusty

Schwag Merchant

From: Medicine Hat, Alberta, Canada

Registered: 2004-01-18

Posts: 5,986

Website

Re: cleaning orphans not explicitly installed...

Until this feature is added to pacman, you may also be interested in the package pkgsweeper, by rasat. I don't think it's in any of the repos or turs, but it's available from:

http://amlug.net/new-projects/pkgsweepe … eeper.html

---

** Arch Linux Apparel and more ** Arch Linux stickers, laptop bags, jewelery ** I wrote a book on Python 3 ** and one on mental health **

Offline

#12 2004-08-13 15:58:01

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

Some ideas:

1.  Perhaps a tag can be added to all packages that indicates whether the package is "standalone" or a supporting "library".  Samba can be utilized on its own but could be used by another program to browse a network.  Whereas libpng is not useful by itself.

Yeah I did mention this in one of my previous posts, and it might be useful, but like you said, some people will want samba to be treated as an explicitly installed package, and others will treat it as a dep. Maybe the best way to detect if somebody wants a package explicitly installed is if they do so. Rather than giving the decision to the package maintainer.

2.  Implement a notion of changesets (like source versioning) or transactions.  Installing a package and its deps can be tagged with a new local group name.  Then the set of packages could be removed by removing the local group.

I think I see what you're talking about here, but what about the case where I install package A which also installs C, and that becomes part of the "transaction", then later I install package B which also depends on package C, but package C isn't part of the transaction because it was already installed... then I decide I want to remove A, and since C is part of the transaction package B is broken. Am I understanding you correctly?

Thanks for the input!

~Jake B

Offline

#13 2004-08-14 03:54:11

kpiche

Forum Fellow

From: Ottawa, ON, Canada

Registered: 2004-03-30

Posts: 246

Website

Re: cleaning orphans not explicitly installed...

That sounds about right, good example.  If a tagged set of packages A and C is installed and then B which depends on C is installed then the removal of the set AC would have to respect B's usage and leave C there.  But then should C be combined with B into set BC?

I have a nagging feeling that this idea is an overly complex version of the not/explicitly installed flag idea.

As for the standalone/library concept I guess it could have a default set by the maintainer but changeable by the local admin...

Offline

#14 2004-08-17 02:48:31

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

I'm making good progress. I've already got kdebase installing and removing correctly on a clean (uml) system. takaitra is helping me to test, and if anybody else is interested in helping test, or anything else let me know. The next thing I'm going to work on is if the user installs groups or "provides" packages, also making updates retain the installtype.

~Jake B

Offline

#15 2004-08-17 19:58:50

apeiro

Daddy

From: Victoria, BC, Canada

Registered: 2002-08-12

Posts: 771

Website

Re: cleaning orphans not explicitly installed...

An alternative would be to do more or less the same as when installing a group: Instead of asking "Proceed with upgrade?" ask "Remove all the above packages?" and if the user says no then prompt for each package seperate.

Yea, this functionality is already there, but only works for maintainer-defined package groups.

[root@pluto jvinet]# pacman -R xfce4
:: group xfce4:
    gtk-xfce-engine libxfce4mcs libxfce4util libxfcegui4 xfce-mcs-manager 
    xfce-mcs-plugins xfce-utils xfce4-iconbox xfce4-panel xfce4-themes 
    xfdesktop xffm xfprint xfwm4 
    Remove whole content? [Y/n]

I think the most simple solution is the best here.  If a package appears in the targets list in an -A/-U/-S operation, then set a flag when it's installed.  It's not bulletproof, but it will work for most cases.

Offline

#16 2004-08-17 23:42:30

dp

Member

From: Zürich, Switzerland

Registered: 2003-05-27

Posts: 3,378

Website

Re: cleaning orphans not explicitly installed...

if anything is added to a/the db, then it should be reversed dependences ... and if there are none (same case like your F==0), then it is a pkg at the end of the deps-tree and can be removed

---

The impossible missions are the only ones which succeed.

Offline

#17 2004-08-18 01:12:02

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

if anything is added to a/the db, then it should be reversed dependences ... and if there are none (same case like your F==0), then it is a pkg at the end of the deps-tree and can be removed

You are 100% right, this is currently in place, and that's what I'm using to implement this.

I think the most simple solution is the best here.  If a package appears in the targets list in an -A/-U/-S operation, then set a flag when it's installed.  It's not bulletproof, but it will work for most cases.

What I'm actually doing is like this (so far):
If a package is being upgraded, take the flag from the old version
If a package is being installed (either -A, or -S) and it's in the target list (either the pkg itself, part of a group in the list, or being installed because it provides something in the list) then mark it as explicit.

Any thoughts on command line options, or config file options? Is there any reason to have a config file option to disable this functionality?

I already added a --noremorphans that will disable removing orphans. There needs to be a way to mark an existing package as a dep or explicit, I'm thinking if you just do "pacman -A existingpackage" it should mark it as explicit, and maybe something like "pacman -A --markdep existingpackage" should mark it as a dep. Any thoughts? If you mark a package as a dep should it scan for orphans and remove them at that point, or maybe I should add an option to scan the entire database for orphans for removal, basically that would entail looking for packages installed as deps with no required by's and recursively removing and scanning (I already have a function that does the hard part).

~Jake B

Offline

#18 2004-08-21 22:57:47

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

The patch seems to be working really well now... but I would really like to see how it works for some other people. I have a subversion repo at http://jakeb.dyndns.org/pacman. Please be nice to it because it's on a cable line, and I only have 30K upstream. For those of you who haven't used subversion... it's a lot like cvs, you can check out a copy of the tree like this:

pacman -Sy subversion
svn checkout http://jakeb.dyndns.org/pacman/trunk pacman

If you want to test, I would recomend using Usermode Linux to prevent any possibility of messing up your pacman database. If you need help setting it up, contact me on AIM (ojbneto) or email (JakeB@iName.com).

~Jake B

edit: fixed link, it had a period included in the URL

Offline

#19 2004-08-23 07:08:14

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

I just patched the codebase to reflect the changes in 2.8.4

Offline

#20 2004-08-30 05:06:34

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

http://bugs.archlinux.org/index.php?do=details&id=1348

Offline

#21 2004-08-31 14:44:54

punkrockguy318

Member

From: New Jersey

Registered: 2004-02-15

Posts: 711

Website

Re: cleaning orphans not explicitly installed...

sounds like a good idea... i hope to see it in pacman 

---

If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing.   1 Corinthians 13:2

Offline

Pages: 1

• Index
• » Pacman & Package Upgrade Issues
• » cleaning orphans not explicitly installed...

lanrat

Member

From: Poland

Registered: 2003-10-28

Posts: 1,274

Re: cleaning orphans not explicitly installed...

I'm to tired today to really think about it logically :-) but there is also /var/log/pacman.log which will tell you what was installed after what and when ;-) (though having something automatic would be nice too).

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

One question, What if you installed gnome-desktop first, then you decided you needed samba but since it was already installed you wouldn't have to install it... then things break (anyway) when you remove gnome-desktop.

Good point...
There could be a way to mark samba as explicitly installed post-installation. I'm not sure if this is a good idea, but there is the option of having a flag in the package file itself to say weather it is more of a dep (library or something) or a useful package (samba, etc). I think that would cause more problems than anything.

I'm to tired today to really think about it logically Smile but there is also /var/log/pacman.log which will tell you what was installed after what and when Wink (though having something automatic would be nice too).

Yes, but that logs all installs, including deps, and doesn't diferentiate between deps and explicitly installed packages. Thanks for pointint it out though.

by the way just to be clear, this isn't an origional idea... it is implemented in Debian very well, and sort of in Gentoo (and maybe some others I don't know about)

~Jake B

lanrat

Member

From: Poland

Registered: 2003-10-28

Posts: 1,274

Re: cleaning orphans not explicitly installed...

Yes, but that logs all installs, including deps, and doesn't diferentiate between deps and explicitly installed packages. Thanks for pointint it out though.

True. But It would be easier (I think) to add an option to pacman to write another flag next to date in the log file (something like: D - dependency install, E - explicit install). Since the log is already there and all information is available to pacman during install....

Also if you analyze it in the chronologial order then you can see for example if samba was installed as a dependency or explicitly by a user. This of course is not 100% bulletproof because dependencies change in time, some people do installs/removals with -Sd/Rd options, etc, etc. Maybe if pacman would also save in the log name of the package that requested other package to be installed as a dependency - this could help. In other words pacman log should consit of every detailed command issued by a user.

by the way just to be clear, this isn't an origional idea... it is implemented in Debian very well, and sort of in Gentoo (and maybe some others I don't know about)

~Jake B

IIRC it's not that original here too. If you search the forums you will find some ideas and even applications/scripts that do (more or less) what you want.

i3839

Member

Registered: 2004-02-04

Posts: 1,185

Re: cleaning orphans not explicitly installed...

An alternative would be to do more or less the same as when installing a group: Instead of asking "Proceed with upgrade?" ask "Remove all the above packages?" and if the user says no then prompt for each package seperate.

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

True. But It would be easier (I think) to add an option to pacman to write another flag next to date in the log file (something like: D - dependency install, E - explicit install). Since the log is already there and all information is available to pacman during install....

ahh, I see your point. It might not be so easy though because it would have to watch out for removals, and reinstalls -- though simply looking for the last install would probably work in most cases. IMHO It would probably be cleaner to add the flag to the package database, after all it seems a log is for seeing what has been done in the past, and the database is for keeping data about the packages. Lots of stuff could have been stored in and calculated from the log file.  Would there be a lot of resistance to adding this to the database? Arch isn't at version 1 yet, so maybe it wouldn't be such a big deal to change the database slightly, especially if it didn't break any current systems.

To keep backwards compatability existing packages could be flagged as installed explicitly by default. This would prevent wanted packages from being treated as orphans, but would also prevent orphans from being treated as orphans. However this would make things continue to work until a fresh install, or one could go thorugh and manually mark the undesired packages as deps.

edit: I found a simmilar proposal here:  http://bbs.archlinux.org/viewtopic.php?p=11730#11730

Xentac

Forum Fellow

From: Victoria, BC

Registered: 2003-01-17

Posts: 1,797

Website

Re: cleaning orphans not explicitly installed...

This is something that has been mentioned and is on the todo list.  Feel free to co-ordinate with Judd about it (read: send him an email).

Personally, I agree that adding a flag to the database is the best bet and also not a problem (we've done it numerous times without affecting backwards compatibility).  Log files get rotated, can't grow forever, and aren't reliable.

---

I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

kpiche

Forum Fellow

From: Ottawa, ON, Canada

Registered: 2004-03-30

Posts: 246

Website

Re: cleaning orphans not explicitly installed...

Some ideas:

1.  Perhaps a tag can be added to all packages that indicates whether the package is "standalone" or a supporting "library".  Samba can be utilized on its own but could be used by another program to browse a network.  Whereas libpng is not useful by itself.

2.  Implement a notion of changesets (like source versioning) or transactions.  Installing a package and its deps can be tagged with a new local group name.  Then the set of packages could be removed by removing the local group.

Takaitra

Member

From: Minnesota

Registered: 2004-05-24

Posts: 10

Re: cleaning orphans not explicitly installed...

jbNet, I searched searched the forums looking for the exact functionality you described and found your thread. The 'pacman -Qe' gave me a list of packages to look at removing but it's no 'emerge depclean' as I could do in Gentoo. It would be great to have the same list as given by 'pacman -Qe' without the explicitly installed packages.

I just started using Arch, and really like what I see in it's philosophy, design and community. I was actually thinking about starting my own distribution, but then spent some time on distrowatch, and found Arch. I am a Junior at Oregon Institute of Technology (don't judge them on their website), and am looking for something to contribute to the OSS community.

I'm also a new user of Arch and am a junior at the University of St. Thomas. If you start work on this, I'd like to help out.

Dusty

Schwag Merchant

From: Medicine Hat, Alberta, Canada

Registered: 2004-01-18

Posts: 5,986

Website

Re: cleaning orphans not explicitly installed...

Until this feature is added to pacman, you may also be interested in the package pkgsweeper, by rasat. I don't think it's in any of the repos or turs, but it's available from:

http://amlug.net/new-projects/pkgsweepe … eeper.html

---

** Arch Linux Apparel and more ** Arch Linux stickers, laptop bags, jewelery ** I wrote a book on Python 3 ** and one on mental health **

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

Some ideas:

1.  Perhaps a tag can be added to all packages that indicates whether the package is "standalone" or a supporting "library".  Samba can be utilized on its own but could be used by another program to browse a network.  Whereas libpng is not useful by itself.

Yeah I did mention this in one of my previous posts, and it might be useful, but like you said, some people will want samba to be treated as an explicitly installed package, and others will treat it as a dep. Maybe the best way to detect if somebody wants a package explicitly installed is if they do so. Rather than giving the decision to the package maintainer.

2.  Implement a notion of changesets (like source versioning) or transactions.  Installing a package and its deps can be tagged with a new local group name.  Then the set of packages could be removed by removing the local group.

I think I see what you're talking about here, but what about the case where I install package A which also installs C, and that becomes part of the "transaction", then later I install package B which also depends on package C, but package C isn't part of the transaction because it was already installed... then I decide I want to remove A, and since C is part of the transaction package B is broken. Am I understanding you correctly?

Thanks for the input!

~Jake B

kpiche

Forum Fellow

From: Ottawa, ON, Canada

Registered: 2004-03-30

Posts: 246

Website

Re: cleaning orphans not explicitly installed...

That sounds about right, good example.  If a tagged set of packages A and C is installed and then B which depends on C is installed then the removal of the set AC would have to respect B's usage and leave C there.  But then should C be combined with B into set BC?

I have a nagging feeling that this idea is an overly complex version of the not/explicitly installed flag idea.

As for the standalone/library concept I guess it could have a default set by the maintainer but changeable by the local admin...

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

I'm making good progress. I've already got kdebase installing and removing correctly on a clean (uml) system. takaitra is helping me to test, and if anybody else is interested in helping test, or anything else let me know. The next thing I'm going to work on is if the user installs groups or "provides" packages, also making updates retain the installtype.

~Jake B

apeiro

Daddy

From: Victoria, BC, Canada

Registered: 2002-08-12

Posts: 771

Website

Re: cleaning orphans not explicitly installed...

An alternative would be to do more or less the same as when installing a group: Instead of asking "Proceed with upgrade?" ask "Remove all the above packages?" and if the user says no then prompt for each package seperate.

Yea, this functionality is already there, but only works for maintainer-defined package groups.

[root@pluto jvinet]# pacman -R xfce4
:: group xfce4:
    gtk-xfce-engine libxfce4mcs libxfce4util libxfcegui4 xfce-mcs-manager 
    xfce-mcs-plugins xfce-utils xfce4-iconbox xfce4-panel xfce4-themes 
    xfdesktop xffm xfprint xfwm4 
    Remove whole content? [Y/n]

I think the most simple solution is the best here.  If a package appears in the targets list in an -A/-U/-S operation, then set a flag when it's installed.  It's not bulletproof, but it will work for most cases.

dp

Member

From: Zürich, Switzerland

Registered: 2003-05-27

Posts: 3,378

Website

Re: cleaning orphans not explicitly installed...

if anything is added to a/the db, then it should be reversed dependences ... and if there are none (same case like your F==0), then it is a pkg at the end of the deps-tree and can be removed

---

The impossible missions are the only ones which succeed.

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

if anything is added to a/the db, then it should be reversed dependences ... and if there are none (same case like your F==0), then it is a pkg at the end of the deps-tree and can be removed

You are 100% right, this is currently in place, and that's what I'm using to implement this.

I think the most simple solution is the best here.  If a package appears in the targets list in an -A/-U/-S operation, then set a flag when it's installed.  It's not bulletproof, but it will work for most cases.

What I'm actually doing is like this (so far):
If a package is being upgraded, take the flag from the old version
If a package is being installed (either -A, or -S) and it's in the target list (either the pkg itself, part of a group in the list, or being installed because it provides something in the list) then mark it as explicit.

Any thoughts on command line options, or config file options? Is there any reason to have a config file option to disable this functionality?

I already added a --noremorphans that will disable removing orphans. There needs to be a way to mark an existing package as a dep or explicit, I'm thinking if you just do "pacman -A existingpackage" it should mark it as explicit, and maybe something like "pacman -A --markdep existingpackage" should mark it as a dep. Any thoughts? If you mark a package as a dep should it scan for orphans and remove them at that point, or maybe I should add an option to scan the entire database for orphans for removal, basically that would entail looking for packages installed as deps with no required by's and recursively removing and scanning (I already have a function that does the hard part).

~Jake B

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

The patch seems to be working really well now... but I would really like to see how it works for some other people. I have a subversion repo at http://jakeb.dyndns.org/pacman. Please be nice to it because it's on a cable line, and I only have 30K upstream. For those of you who haven't used subversion... it's a lot like cvs, you can check out a copy of the tree like this:

pacman -Sy subversion
svn checkout http://jakeb.dyndns.org/pacman/trunk pacman

If you want to test, I would recomend using Usermode Linux to prevent any possibility of messing up your pacman database. If you need help setting it up, contact me on AIM (ojbneto) or email (JakeB@iName.com).

~Jake B

edit: fixed link, it had a period included in the URL

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

I just patched the codebase to reflect the changes in 2.8.4

jbNet

Member

From: Klamath Falls, OR, USA

Registered: 2004-08-12

Posts: 34

Re: cleaning orphans not explicitly installed...

http://bugs.archlinux.org/index.php?do=details&id=1348

punkrockguy318

Member

From: New Jersey

Registered: 2004-02-15

Posts: 711

Website

Re: cleaning orphans not explicitly installed...

sounds like a good idea... i hope to see it in pacman 

---

If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing.   1 Corinthians 13:2