(apologies to Johannes for initially replying to him and not the list on accident) On 6/8/07, Johannes Winkelmann <jw@smts.ch> wrote: * snip *
c. Some package may have no dependent packages, but you want to keep them nevertheless. Consider this real world example: the window manager 'openbox' comes with a configuration tool, called 'obconf'. The 'obconf' port from the portdb depends on 'openbox'. Now imagine you've had openbox installed before, and decide to try 'obconf'; after a while you realize you don't like it. 'prt-get remove obconf' as you imagine it would then remove openbox as well, since there are no other packages depending on it on the system. Here, you have to bring in external knowledge about the user's preferences.
One of my credos for prt-get has always been "If you can't do it right, don't do it at all", and with that in mind, adding a 'depremove' feature which would potentially do the wrong thing at times seemed a bad idea.
I think you'd need a way to separate 'libraries' (packages that merely exist to add functionality to other packages) from 'binaries' (packages which contain actual applications the user runs). Of course, for example, the sqlite library also contains a binary tool for manipulating sqlite databases. So, you'd basically have to add metadata to Pkgfiles in the comment section, in which case you'd run the risk of being burnt by a ports update breaking your system. Or, you could add metadata to the package database, which would really start turning the package manager into something more like rpm or dpkg. I've really been frustrated by this problem for years, and the only solutions I've come up with are: 1. Stop caring that you may have some extra packages you don't need lying around (this is actually the best approach unless you are crammed for space). If you run prt-get depinst gnome-terminal, don't expect to get your system back to the pristine state it started in when you first installed crux. 2. Be very careful about installing software. Understand what exactly goes on when you do a prt-get depinst, and keep track of the dependencies on your own. 3. Every now and then, list all your installed ports and find any ports you don't need any more. Nathan
On 6/9/07, Nathan Ladd <nathanladd@gmail.com> wrote:
I think you'd need a way to separate 'libraries' (packages that merely exist to add functionality to other packages) from 'binaries' (packages which contain actual applications the user runs). Of course, for example, the sqlite library also contains a binary tool for manipulating sqlite databases.
So, you'd basically have to add metadata to Pkgfiles in the comment section, in which case you'd run the risk of being burnt by a ports update breaking your system. Or, you could add metadata to the package database, which would really start turning the package manager into something more like rpm or dpkg.
I've really been frustrated by this problem for years,
:-(
and the only solutions I've come up with are:
1. Stop caring that you may have some extra packages you don't need lying around (this is actually the best approach unless you are crammed for space). If you run prt-get depinst gnome-terminal, don't expect to get your system back to the pristine state it started in when you first installed crux.
hey... you stole my solution ;-)
Nathan _______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
please do not quote signatures -- http://arnuld.blogspot.com/
Hi Nathan, On Fri, Jun 08, 2007 at 17:24:13 -0500, Nathan Ladd wrote:
(apologies to Johannes for initially replying to him and not the list on accident)
No problem :-)
On 6/8/07, Johannes Winkelmann <jw@smts.ch> wrote: [...] I've really been frustrated by this problem for years, and the only solutions I've come up with are:
At the risk of pointing out the obvious, there's a tool called pkgfoster which is included in opt/prt-utils [1] which looks for ports which have no dependencies. Unlike prt-get, it's interactive, so it'll ask for before installing a port, and will remember the decision. This will still require you to decide which ports you want to keep, and which ones you can get rid of, but at least it won't present you the ports which definitely have to stay.
1. Stop caring that you may have some extra packages you don't need lying around (this is actually the best approach unless you are crammed for space). If you run prt-get depinst gnome-terminal, don't expect to get your system back to the pristine state it started in when you first installed crux.
True. There's a slightly excessive path we could walk by keeping track of the list of packages installed or removed by prt-get, and allowing to revert to previous states (a kind of undo history). There was a tool to do that, although you had to set the breakpoints manually, like (mockup, I don't remember how the syntax was exactly): $ prt-state store $ prt-get depinst gnome-terminal [don't like it] $ prt-state revert Although the tool is not available anymore, unless you want multiple states this can be done by simply storing the list of installed packages for 'store' and diff'ing the current list of installed packages against the previously stored one and remove those only in the 2nd list. Of course, this will only work reliably if you do it immediately. With the additional call to 'dependent' this could be made fairly safe, though. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Sat, Jun 09, 2007 at 12:34:50 +0200, Johannes Winkelmann wrote:
Hi Nathan,
On Fri, Jun 08, 2007 at 17:24:13 -0500, Nathan Ladd wrote:
(apologies to Johannes for initially replying to him and not the list on accident)
No problem :-)
On 6/8/07, Johannes Winkelmann <jw@smts.ch> wrote: [...] I've really been frustrated by this problem for years, and the only solutions I've come up with are:
At the risk of pointing out the obvious, there's a tool called pkgfoster which is included in opt/prt-utils [1]
Reference: 1. http://crux.nu/Main/PrtUtils -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hi, I have created a x86_64 version of crux. It is a pure 64bit version and works with the normal filestructure. I think the most crux ports are compatible with crux86_64, but at the moment i haven't checked all ports in opt and contrib. Only the core of glibc, gcc, binutils and some extra packages are modified. I have greated an ISO Image with the normal set of precompiled packages. You can download the iso file at http://ecarux.de/crux86_64/ If the crux developers are interested in merge crux86_64 in the normal crux, just contact me. regards Hannes -- Hannes Mayer ecarux Computer-Service Cuxhavener Straße 266 21149 Hamburg Tel.: 040 / 98235882 mail: kontakt@ecarux.de Homepage: ecarux.de Steuernummer: 06/276/18018
On Mon, 11 Jun 2007 01:15:52 +0200 Hannes Mayer <kontakt@ecarux.de> wrote:
Hi,
I have created a x86_64 version of crux. It is a pure 64bit version and works with the normal filestructure. I think the most crux ports are compatible with crux86_64, but at the moment i haven't checked all ports in opt and contrib. Only the core of glibc, gcc, binutils and some extra packages are modified. I have greated an ISO Image with the normal set of precompiled packages. You can download the iso file at http://ecarux.de/crux86_64/ If the crux developers are interested in merge crux86_64 in the normal crux, just contact me.
Good work :) I'll have a look at this next weekend. As some of you might be aware I am also working on a x86_64 port of CRUX, however my version provides multilib support. If anyone is interested in a multilib version, my port repositories are available at http://crux64.die.net.au I'd also be interested in integrating your ports into my multiarch repository. -- Lucas Hazel <lucas@die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." =================================================
Hannes Mayer wrote:
Hi,
I have created a x86_64 version of crux. It is a pure 64bit version and works with the normal filestructure. I think the most crux ports are compatible with crux86_64, but at the moment i haven't checked all ports in opt and contrib. Only the core of glibc, gcc, binutils and some extra packages are modified. I have greated an ISO Image with the normal set of precompiled packages. You can download the iso file at http://ecarux.de/crux86_64/ If the crux developers are interested in merge crux86_64 in the normal crux, just contact me.
regards Hannes Great, I've been wanting to upgrade my old (CRUX 2.1) database server. All it runs is Postgresql, nothing else. I keep it to a bare minimum of installed software and just run Postgresql on it. I've been thinking of doing it with Debian but now if this one works OK then I wont need to.
I probably wont have it running for a few weeks but will report back once I've got it installed. Joe
On Mon, Jun 11, 2007 at 01:15:52AM +0200, Hannes Mayer wrote:
Hi,
Hi Hannes,
I have created a x86_64 version of crux. It is a pure 64bit version and works with the normal filestructure.
thanks for your work, I've added a link at crux.nu [1]. Doing it that way seems to be much more CRUXish than dealing with that multilib crap, but that's only my personal opinion. Greetings Juergen [1] http://crux.nu/Main/Links -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On 6/9/07, Johannes Winkelmann <jw@smts.ch> wrote:
At the risk of pointing out the obvious, there's a tool called pkgfoster which is included in opt/prt-utils [1] which looks for ports which have no dependencies. Unlike prt-get, it's interactive, so it'll ask for before installing a port, and will remember the decision.
Since it's interactive, I considered pkgfoster to really be a tool to assist manual dependency removal.
True. There's a slightly excessive path we could walk by keeping track of the list of packages installed or removed by prt-get, and allowing to revert to previous states (a kind of undo history).
There was a tool to do that, although you had to set the breakpoints manually, like (mockup, I don't remember how the syntax was exactly):
$ prt-state store $ prt-get depinst gnome-terminal [don't like it] $ prt-state revert
Unfortunately, as you mentioned, this would break if you continued to add/remove packages that had dependencies on anything underneath gnome-terminal.
Although the tool is not available anymore, unless you want multiple states this can be done by simply storing the list of installed packages for 'store' and diff'ing the current list of installed packages against the previously stored one and remove those only in the 2nd list. Of course, this will only work reliably if you do it immediately. With the additional call to 'dependent' this could be made fairly safe, though.
HTH, Johannes
What might help is to have a prt-get log that logs all activity--i.e. a readout for 'prt-get depinst obconf' would look like this: log: installed dependency 'openbox' for target 'obconf' log: installed target 'obconf' This would help with the occasional manual system cleanup. Also, if the logging were sufficiently verbose, a script could parse it and figure out how to remove a packages dependencies safely. Nathan
Shameless plug... I wrote a perl script a while back to find obsolete and orphaned packages(never knew about pkgfoster before). It doesn't do the work of removing the packages, it's more of a summary tool but it can definitely help with managing this dilemma some.
Hi Nathan, On Mon, Jun 11, 2007 at 11:49:37 -0500, Nathan Ladd wrote:
On 6/9/07, Johannes Winkelmann <jw@smts.ch> wrote:
At the risk of pointing out the obvious, there's a tool called pkgfoster which is included in opt/prt-utils [1] which looks for ports which have no dependencies. Unlike prt-get, it's interactive, so it'll ask for before installing a port, and will remember the decision.
Since it's interactive, I considered pkgfoster to really be a tool to assist manual dependency removal.
Not sure if this is of any help, but I just tried a tool which pulled in a couple of new deps, and when I wanted to get rid of them I though I'd make the script somewhat more elaborate than necessary to maybe make it useful for others. It basically does what Alan and I discussed in [1], removing dependencies which have no dependent ports, but it'll ask for every package to make sure we can avoid the 'obconf/openbox' problem mentioned in an earlier mail in this thread. It is not trying to be smart and detect binaries or optional dependency stuff, so that's still up to the user; however, it might be more convenient than pkgfoster in a case where you want to get rid of a specific dependency subtree, like in the gnome-terminal use case (BTW if anyone does the gnome-terminal test, please let me know about the results :-)). You can have a look at the script here http://jw.smts.ch/files/crux/dep-remove The session could look like this: # ./dep-remove gst-plugins-good Remove 'gst-plugins-good' (y/N) ? y Remove 'gst-plugins-base' (y/N) ? y Remove 'libvisual' (y/N) ? y Remove 'libtheora' (y/N) ? y Remove 'gstreamer' (y/N) ? y Remove 'liboil' (y/N) ? y Log available in '/tmp/dep-remove-2467.log' # cat '/tmp/dep-remove-2467.log' Remove log for dep-remove gst-plugins-good Removed: gst-plugins-good Removed: gst-plugins-base Removed: libvisual Removed: libtheora Removed: gstreamer Removed: liboil # Enjoy, Johannes References: 1. http://lists.crux.nu/pipermail/crux/2007-May/007510.html -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On 6/16/07, Johannes Winkelmann <jw@smts.ch> wrote:
It basically does what Alan and I discussed in [1], removing dependencies which have no dependent ports, but it'll ask for every package to make sure we can avoid the 'obconf/openbox' problem mentioned in an earlier mail in this thread. It is not trying to be smart and detect binaries or optional dependency stuff, so that's still up to the user; however, it might be more convenient than pkgfoster in a case where you want to get rid of a specific dependency subtree,
"pkgfoster" is good but it asks for name, function and knowledge of every package installed on the system and i think to know that is quite tedious task.
like in the gnome-terminal use case (BTW if anyone does the gnome-terminal test, please let me know about the results :-)).
You can have a look at the script here http://jw.smts.ch/files/crux/dep-remove
The session could look like this: # ./dep-remove gst-plugins-good Remove 'gst-plugins-good' (y/N) ? y Remove 'gst-plugins-base' (y/N) ? y Remove 'libvisual' (y/N) ? y Remove 'libtheora' (y/N) ? y Remove 'gstreamer' (y/N) ? y Remove 'liboil' (y/N) ? y Log available in '/tmp/dep-remove-2467.log' # cat '/tmp/dep-remove-2467.log' Remove log for dep-remove gst-plugins-good Removed: gst-plugins-good Removed: gst-plugins-base Removed: libvisual Removed: libtheora Removed: gstreamer Removed: liboil #
Enjoy, Johannes
i think i will enjoy it :-) it comes as a relpacement for "pacman -Rcs" or "emerge -C && emerge --depclean"
References: 1. http://lists.crux.nu/pipermail/crux/2007-May/007510.html
hey.. that's me -) -- http://arnuld.blogspot.com/
participants (8)
-
arnuld -
Hannes Mayer -
Joe Gilmour -
Johannes Winkelmann -
Juergen Daubert -
Lucas Hazel -
Nathan Ladd -
Nick Deubert