Dear all,
This is something new and missing for linux. I think it's a great idea. The following wiki page explains clearly.
https://wiki.ubuntu.com/PackageDependencyManagement
On 4/21/06, Leon sdl.web@gmail.com wrote:
Dear all,
This is something new and missing for linux. I think it's a great idea. The following wiki page explains clearly.
automatic removal of dependancies.. will only work if all applications and scripts on the system are managed by the package management system. That means that nothing on the system can be installed via source which makes it outside the scope of the package management system which may be using an "indirect" dependancy. Nothing can be install from an alternative catelog like CPAN.. which may be using an "indirect" dependancy. Nothing can be written locally as a script, shell or perl or python or php or otherwise... that may use an "indirect" dependancy.
This only robustly works if every library and every executable and every intepretable script which could be calling other executables on the system is strictly managed by the package management system. Snowball's chance in that happening on a anything close to 90% of deployed systems. Whether its multiuser moderate to large network deployments, or someone's home workstation the chance that a system is rpm pure for every executable and script on the system is slim.
-jef
"Jeff Spaleta" jspaleta@gmail.com writes:
On 4/21/06, Leon sdl.web@gmail.com wrote:
Dear all,
This is something new and missing for linux. I think it's a great idea. The following wiki page explains clearly.
automatic removal of dependancies.. will only work if all applications and scripts on the system are managed by the package management system. That means that nothing on the system can be installed via source which makes it outside the scope of the package management system which may be using an "indirect" dependancy. Nothing can be install from an alternative catelog like CPAN.. which may be using an "indirect" dependancy. Nothing can be written locally as a script, shell or perl or python or php or otherwise... that may use an "indirect" dependancy.
This only robustly works if every library and every executable and every intepretable script which could be calling other executables on the system is strictly managed by the package management system. Snowball's chance in that happening on a anything close to 90% of deployed systems. Whether its multiuser moderate to large network deployments, or someone's home workstation the chance that a system is rpm pure for every executable and script on the system is slim.
-jef
I think you didn't get the idea right.
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
Ubuntu put this *high* priority for the next release after dapper. After reading its wiki page, it make sense to me. And I believe it will be useful.
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
I don't get it. Why? What's the point of this?
-- As a boy I jumped through Windows, as a man I play with Penguins.
On Fri, Apr 21, 2006 at 06:49:58PM -0500, Arthur Pemberton wrote:
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
I don't get it. Why? What's the point of this?
The point, I imagine is something like: "With gnucash finally moved to GTK2, all the actual programs I had installed that used various GTK1 and GNOME1 libraries installed no longer use them. These libraries, which aren't real applications but only for support of end-user applications, take up extra space. I'd like them to be automatically removed." or "I told yum to install application X, and it had to install 10 other packages for dependencies. I now want to remove application X, and it sure would be nice if those dependencies all got removed at the same time automatically, since nothing else uses them. After all, it's easier for me to just remember end-user application X, which I actually use directly, than to remember it and the list of support libraries that got installed with it."
Whether it's worth the effort involved to save the disk space and all, I don't know.
John Thacker
On 4/21/06, Leon sdl.web@gmail.com wrote:
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
Oh i get it.. and what I'm saying is I think you under-estimate how difficult it will be to robustly use automatical removal of dependancies marked for autoremoval without causing problems with crap that is not tracked by the package management system. I think you underestimate how often people install tools that were part of an automatically included dependancy which end up being used in scripts that were written locally that are not tracked in the rpm system. Little perl scripts, little shell scripts, little python scripts, little php scripts. Hell anyone running any sort of website with php enabled is most likely running some sort of not rpm managed php junk that is in fact configured to exec other binaries, binaries which may be marked as an indirect dependancy of some other package which would be removed via the automatic dependance removal feature.
Ubuntu put this *high* priority for the next release after dapper. After reading its wiki page, it make sense to me. And I believe it will be useful.
Sure it will be useful to some segment of the userbase I don't dispute that. What I think that it will also be a huge problem when people start turning that feature on and they see tools their homebrew scripts needed start disappearing on a large scale. I guess time will tell. I hope for the sake of Ubuntu users the people who implement this provide a cookie-cutter way for a local admin to exclude certain packages from the autoremove pool to prevent random script breakage. Or even better they provide a tool which can audit perl,python,ruby,php,shell scripts that are not being managed by the package management system before autoremovals of deps happen.
-jef"Oh look I dont really need the sysstat package installed.. I'll just remove it from my system. Oh look sysstat is the only think which explictly needs the vixie-cron package. Hey look vixie-cron is marked as something that package manager can automatically remove because it was not an explicit application that I ask to install, it was pulled in by sysstat at install time. Oh crap my cron system was removed.. now none of my per-user cron jobs run. Yippie for ease-of-use software innovation!!!!!"spaleta
On Fri, 2006-04-21 at 20:18 -0400, Jeff Spaleta wrote:
On 4/21/06, Leon sdl.web@gmail.com wrote:
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
Oh i get it.. and what I'm saying is I think you under-estimate how difficult it will be to robustly use automatical removal of dependancies marked for autoremoval without causing problems with crap that is not tracked by the package management system. I think you underestimate how often people install tools that were part of an automatically included dependancy which end up being used in scripts that were written locally that are not tracked in the rpm system. Little perl scripts, little shell scripts, little python scripts, little php scripts. Hell anyone running any sort of website with php enabled is most likely running some sort of not rpm managed php junk that is in fact configured to exec other binaries, binaries which may be marked as an indirect dependancy of some other package which would be removed via the automatic dependance removal feature.
It really isn't needed to do it automatically. Debian have a package called debfoster (at least they had in 2002), which checks the interdependencies of all your packages and for then asks whether you want to remove each package that aren't needed by any others, e.g.:
Package A keeps these packages installed: G, K, O, R Do you wish to keep package A? [Y/n]
This has the obvious advantage that you don't have to add yet a piece of info to the ever-bloated rpm database.
Gentoo also do it. IIRC it has a command which lists all packages that were not installed explicitly and which no other package depends upon (which is a nice, logical list), but then they have to ruin an otherwise nice feature by automatically removing all said packages after 10 seconds if not interrupted.
On Sat, 22 Apr 2006, Mark Rosenstand wrote:
It really isn't needed to do it automatically. Debian have a package called debfoster (at least they had in 2002), which checks the interdependencies of all your packages and for then asks whether you want to remove each package that aren't needed by any others, e.g.:
Package A keeps these packages installed: G, K, O, R Do you wish to keep package A? [Y/n]
This has the obvious advantage that you don't have to add yet a piece of info to the ever-bloated rpm database.
Gentoo also do it. IIRC it has a command which lists all packages that were not installed explicitly and which no other package depends upon (which is a nice, logical list), but then they have to ruin an otherwise nice feature by automatically removing all said packages after 10 seconds if not interrupted.
Checking the dependencies is the easy part. What gets less trivial is things like this:
[pmatilai@cs181072240 ~]$ rpm -e --test grub [pmatilai@cs181072240 ~]$
Oops, nothing needs grub, so it can be removed safely, right?
- Panu -
On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote:
Checking the dependencies is the easy part. What gets less trivial is things like this:
[pmatilai@cs181072240 ~]$ rpm -e --test grub [pmatilai@cs181072240 ~]$
Oops, nothing needs grub, so it can be removed safely, right?
The Debian tool assumes that its users are capable of brain activity. I don't know if this is a problem in the Fedora case. Anyway, it does have a couple of more options than Y/n, one of them being 'i' which prints the description of the package, so it's easy to get a pretty good clue if you're uncertain whether you need the package.
Of course this is where the "explicitly installed" attribute is useful. I assume glibc, grub, udev etc. are all explicitly installed by anaconda.
On 4/22/06, Mark Rosenstand mark@borkware.net wrote:
Of course this is where the "explicitly installed" attribute is useful. I assume glibc, grub, udev etc. are all explicitly installed by anaconda.
The smallest group of packages which you can be sure were explicitly installed are the mandatory members of the "Core" group in the comps.xml file for Fedora Core. Since Fedora's installer has the ability to use kickstart for highly customized installs, you can not be reasonable sure that any other specific package will be "explicitly" installed. My vixie-cron example illustrates that problem. vixie-cron is a mamber of the "Base" group which kickstart installs may or may not use so some installs may not "explicitly" ask vixie-cron to be installed and it may be pulled in by sysstat. Or it maybe explicitly removed at some later day and then pulled in by a sysstat install. "explicit" dependancy marking is an unreliable measure of how actively that dependacy is being used on the system and can not be the basis of a robust automatic dependancy removal process.
I have no problem with a set of tools that help admins review leaf nodes in their packageset. But I have concern for any tool that offers to automatically remove leaf nodes...based solely on information which can be tracked by the package management system.. I firmly belief that leaf node removal requires active human review and the process should not be condensed into a set of simplified y/n/cancel dialogs. Things like how frequently/recently the files associated with the package have been accessed by un-dependant executables and libraries (excluding prelink) are important factors to consider.. factors which live outside the available package management information.
-jef
I have this little snippet as ~/bin/rpm-listunused
#!/bin/sh
rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg done
It will simply list all packages where no files have been accessed the last 6 months. I believe it has been posted here before (or I might have picked it up somewhere else), but anyway something like this would probably more helpful than only looking at the dependencies if one is trying to determine what packages can safely be removed.
Rgds.
Ola Thoresen
On 4/22/06, Ola Thoresen redhat@olen.net wrote:
It will simply list all packages where no files have been accessed the last 6 months. I believe it has been posted here before (or I might have picked it up somewhere else), but anyway something like this would probably more helpful than only looking at the dependencies if one is trying to determine what packages can safely be removed.
doesn't prelink operation on libraries nullify much of the value of such a script? If prelink operation changes the access time, you'll basically get false positives for every library prelink touches.
-jef
2006-04-22 "Jeff Spaleta" jspaleta@gmail.com wrote
On 4/22/06, Ola Thoresen redhat@olen.net wrote:
It will simply list all packages where no files have been accessed the last 6 months. I believe it has been posted here before (or I might have picked it up somewhere else), but anyway something like this would probably more helpful than only looking at the dependencies if one is trying to determine what packages can safely be removed.
doesn't prelink operation on libraries nullify much of the value of such a script? If prelink operation changes the access time, you'll basically get false positives for every library prelink touches.
After a stat of the files in /lib it seems like you are right, so with prelink running every night you will never catch unsed libs in /[usr/]lib{,64} and other paths where prelink runs. But on the other hand, it will also catch it if your php-script is using something that would otherwise get removed (becuase it was auto-installed). I don't claim this to be the one true solution, it is just a simple way to list at least some installed but unused packages.
Maybe a simple prelink-patch wich restores the A-time of the files it prelinks would be a possible path.. hmm....
Rgds.
Ola Thoresen
"Jeff Spaleta" jspaleta@gmail.com writes:
On 4/22/06, Mark Rosenstand mark@borkware.net wrote:
Of course this is where the "explicitly installed" attribute is useful. I assume glibc, grub, udev etc. are all explicitly installed by anaconda.
The smallest group of packages which you can be sure were explicitly installed are the mandatory members of the "Core" group in the comps.xml file for Fedora Core. Since Fedora's installer has the ability to use kickstart for highly customized installs, you can not be reasonable sure that any other specific package will be "explicitly" installed. My vixie-cron example illustrates that problem. vixie-cron is a mamber of the "Base" group which kickstart installs may or may not use so some installs may not "explicitly" ask vixie-cron to be installed and it may be pulled in by sysstat. Or it maybe explicitly removed at some later day and then pulled in by a sysstat install. "explicit" dependancy marking is an unreliable measure of how actively that dependacy is being used on the system and can not be the basis of a robust automatic dependancy removal process.
I have no problem with a set of tools that help admins review leaf nodes in their packageset. But I have concern for any tool that offers to automatically remove leaf nodes...based solely on information which can be tracked by the package management system.. I firmly belief that leaf node removal requires active human review and the process should not be condensed into a set of simplified y/n/cancel dialogs. Things like how frequently/recently the files associated with the package have been accessed by un-dependant executables and libraries (excluding prelink) are important factors to consider.. factors which live outside the available package management information.
-jef
Completely agree with your concern. I post this only from the perspective of end users. It's likely to have many obsolete libraries installed when upgrading system from release to release without fresh install.
Anyway this is not a critical feature.
Mark Rosenstand mark@borkware.net wrote:
On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote:
Checking the dependencies is the easy part. What gets less trivial is things like this:
[pmatilai@cs181072240 ~]$ rpm -e --test grub [pmatilai@cs181072240 ~]$
Oops, nothing needs grub, so it can be removed safely, right?
The Debian tool assumes that its users are capable of brain activity.
Riiight...
Idon't know if this is a problem in the Fedora case.
You haven't met many end users, have you? [In any case, a tool like this is completely useless if it /forces/ the user to know about the stuff they have installed... that's 1284 packages currently here, I sure don't know what each one of them does. I'd be real pressed to name more than a hundred. Forget about dependencies...]
Anyway, it does havea couple of more options than Y/n, one of them being 'i' which prints the description of the package, so it's easy to get a pretty good clue if you're uncertain whether you need the package.
Of course this is where the "explicitly installed" attribute is useful. I assume glibc, grub, udev etc. are all explicitly installed by anaconda.
And why should one not be able to also look at "explicitly installed" stuff? Each Linux user goes through the "a distribution a week" phase, the next one is usually the "install everything" that makes for regular flamewars here, spiced up with "... what I can put my hands on"...
On 4/22/06, Horst von Brand vonbrand@inf.utfsm.cl wrote:
And why should one not be able to also look at "explicitly installed" stuff? Each Linux user goes through the "a distribution a week" phase, the next one is usually the "install everything" that makes for regular flamewars here, spiced up with "... what I can put my hands on"...
Write-up an outline of the stages of the linux user evolutionary process, and let's see if we can get it illustrated.
-jef
On Sat, 2006-04-22 at 22:10 -0400, Horst von Brand wrote:
Mark Rosenstand mark@borkware.net wrote:
The Debian tool assumes that its users are capable of brain activity.
Riiight...
Well actually Debian packages have the ability to flag themselves as essential, thus preventing their removal without dire warnings of doom and gloom.
i --\ bash 3.1-2 Description: The GNU Bourne Again SHell Essential: yes Priority: required
On the other hand:
i --\ grub 0.95+cvs20 Description: GRand Unified Bootloader Priority: optional
On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote:
Checking the dependencies is the easy part. What gets less trivial is things like this:
[pmatilai@cs181072240 ~]$ rpm -e --test grub [pmatilai@cs181072240 ~]$
Oops, nothing needs grub, so it can be removed safely, right?
- Panu -
$ cat /etc/fedora-release Fedora Core release 5 (Bordeaux)
$ rpm -q apt --queryformat '%{NAME}-%{VERSION}.%{ARCH}\n' apt-0.5.15lorg3.x86_64
$ head /etc/apt/rpmpriorities Essential: grub termcap ed kbd iproute libtermcap libgcc setserial file
$ sudo apt-get remove grub Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: grub (0.97-5) WARNING: The following essential packages will be removed This should NOT be done unless you know exactly what you are doing! grub 0 upgraded, 0 newly installed, 1 removed and 6 not upgraded. Need to get 0B of archives. After unpacking 1767kB disk space will be freed. You are about to do something potentially harmful To continue type in the phrase 'Yes, do as I say!' ?] No thanks. Abort.
BTW, kickass work on apt, Panu. You have first dibs on my firstborn child. If anyone wants to play with aptitude on Fedora, which already supports the exact feature this thread is about, I've made up a package:
http://www.haxxed.com/rpms/aptitude-0.3.3-1.src.rpm http://www.haxxed.com/rpms/FC5/aptitude-0.3.3-1.x86_64.rpm http://www.haxxed.com/rpms/FC5/aptitude-0.3.3-1.i386.rpm
On FC5 you will need/want apt from the extras-development repo, which supports multilib and yum style metadata.
And a bonus screenshot:
Callum Lerwick <seg <at> haxxed.com> writes:
And a bonus screenshot: http://www.haxxed.com/rpms/Screenshot-aptitude.png
Err, removing system-config-display as "unused" doesn't look like that great an idea to me...
Kevin Kofler
On Sun, 2006-04-23 at 01:10 +0000, Kevin Kofler wrote:
Callum Lerwick <seg <at> haxxed.com> writes:
And a bonus screenshot: http://www.haxxed.com/rpms/Screenshot-aptitude.png
Err, removing system-config-display as "unused" doesn't look like that great an idea to me...
Err, well that's because I marked it as auto installed because I don't really need or want it. Toggling the flag is as simple as hitting M or m. It nicely doubles as an easy way to ask "Hey, do I really need this?".
On Sat, 2006-04-22 at 00:50 +0100, Leon wrote:
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
See Gentoo's "emerge depclean"; portage flags whether the package was installed explicitly or via a dependancy, and depclean allows you to remove any packages not explicitly installed which aren't depended on by anything. Howeve,r also see how many problems they've had with it; it can be a very easy way to make a system unbootable.
It does, however, have a nugget of a good idea embedded in it (which Jef touched on): making it easier for administrators to manage "leaf node" packages. Some use cases I've bumped into:
- Administrator removes a package, and wants to know what other packages depended on it (and only it), so they can see good candidates for removal.
- Administrator wants to browse through packages which nothing depends upon, for auditing for removal.
I'm sure there's a few more. "rpm -q --leafnodes" perhaps, plus a little more verbosity from "yum uninstall" detailing packages this was the sole dependancy for?
- Administrator wants to browse through packages which nothing depends
upon, for auditing for removal.
I'm sure there's a few more. "rpm -q --leafnodes" perhaps, plus a little more verbosity from "yum uninstall" detailing packages this was the sole dependancy for?
1. let's not add more items to rpm's interface. 2. yum doesn't have an 'uninstall' option - it is remove or erase 3. yum-utils contains package-cleanup. 'package-cleanup --leaves --all' lists all programs that nothing depend on 'package-cleanup --leaves' lists all libraries (or as close as it can guess) that nothing depends on.
-sv
Edward S. Marshall wrote:
On Sat, 2006-04-22 at 00:50 +0100, Leon wrote:
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
See Gentoo's "emerge depclean"; portage flags whether the package was installed explicitly or via a dependancy, and depclean allows you to remove any packages not explicitly installed which aren't depended on by anything. Howeve,r also see how many problems they've had with it; it can be a very easy way to make a system unbootable.
It does, however, have a nugget of a good idea embedded in it (which Jef touched on): making it easier for administrators to manage "leaf node" packages. Some use cases I've bumped into:
- Administrator removes a package, and wants to know what other packages
depended on it (and only it), so they can see good candidates for removal.
You can do that quite simply with rpm and dpkg currently. See: http://www.pixelbeat.org/scripts/whatrequires
Pádraig.
On Sat, 2006-04-22 at 00:50 +0100, Leon wrote:
I think you didn't get the idea right.
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
Ubuntu put this *high* priority for the next release after dapper. After reading its wiki page, it make sense to me. And I believe it will be useful.
I want the mathml-fonts fonts installed. I know that "yum install abiword" which I also want will grab them as a dependency.
But suppose I decide that I'm not using AbiWord anymore because I'm doing everything in LaTeX. So I remove AbiWord.
mathml-fonts I still want though - but it was installed as a dependency to abiword, which I have since removed.
Does that mean mathml-fonts will get automatically removed out from under me?
On Tue, 2006-04-25 at 15:23 +0200, Ralf Ertzinger wrote:
Hi.
On Tue, 25 Apr 2006 06:19:16 -0700, Michael A. Peters wrote:
Does that mean mathml-fonts will get automatically removed out from under me?
It may, which is one of the problems with this approach.
Why do people feel the need to argue about problems that were solved years ago? aptitude already provides a very nice interface for this. Its entirely transparent, packages that are flagged auto installed have an "A" flag to the left. This flag can be toggled with a single keystroke. And to top it all off, aptitude gives you a very nice summary of exactly everything its going to do any why before it does it. You can even modify package flags and status right there on the preview page:
http://www.haxxed.com/rpms/Screenshot-aptitude.png
This is how it should be done. Now either just use aptitude, or implement similar functionality in yumex...
On Tue, 2006-04-25 at 14:44 -0500, Callum Lerwick wrote:
On Tue, 2006-04-25 at 15:23 +0200, Ralf Ertzinger wrote:
Hi.
On Tue, 25 Apr 2006 06:19:16 -0700, Michael A. Peters wrote:
Does that mean mathml-fonts will get automatically removed out from under me?
It may, which is one of the problems with this approach.
Why do people feel the need to argue about problems that were solved years ago? aptitude already provides a very nice interface for this. Its entirely transparent, packages that are flagged auto installed have an "A" flag to the left. This flag can be toggled with a single keystroke. And to top it all off, aptitude gives you a very nice summary of exactly everything its going to do any why before it does it. You can even modify package flags and status right there on the preview page:
That assumes that the end user knows what a package is and what it does. Say I had no clue that mathml-fonts were needed to properly view the blog of my Physics professor. I might not even know what mathml is. It just works because something else pulled them in as a dependency.
Now I remove abiword, and the next time I visit his blog, it does not properly display, and I'm clueless as to why.
I think that automatic dependency removal solves a problem that no longer exists when 160 GB hard drives are dirt cheap. The only benefit I see is that with less packages, less bandwidth is needed to keep a system up to date with patches.
On Tue, 2006-04-25 at 22:37 -0700, Michael A. Peters wrote:
That assumes that the end user knows what a package is and what it does. Say I had no clue that mathml-fonts were needed to properly view the blog of my Physics professor. I might not even know what mathml is. It just works because something else pulled them in as a dependency.
Grasping at straws, eh? If firefox supports mathml and needs mathml-fonts to display properly, then perhaps firefox should be depending on mathml-fonts. Or at least putting up some kind of message like "This page cannot be displayed properly, you need mathml-fonts".
On 4/27/06, Callum Lerwick seg@haxxed.com wrote:
Grasping at straws, eh? If firefox supports mathml and needs mathml-fonts to display properly, then perhaps firefox should be depending on mathml-fonts. Or at least putting up some kind of message like "This page cannot be displayed properly, you need mathml-fonts".
The problem is that there's not a good way yet of giving packages 'Suggests'/'Enhances' tags. At the moment all we provide are packages with either 'Requires' or nothing. The idea would be that the package manager would ask the user which suggests/enhances to install (with suggests selected by default).
I would agree that Firefox should show a message about it though.
n0dalus.
On Thu, 2006-04-27 at 14:05 +0930, n0dalus wrote:
The problem is that there's not a good way yet of giving packages 'Suggests'/'Enhances' tags. At the moment all we provide are packages with either 'Requires' or nothing. The idea would be that the package manager would ask the user which suggests/enhances to install (with suggests selected by default).
Which is something Debian packages support. Meh, I've always figured RPM systems seem to get along okay without it, and most of all on my Debian systems I never find myself actually using or caring about Suggests / Recommends anyway, but I guess it's not a horrible idea. What would be nice if we're going to do it is a human friendly short %description as to what exactly each optional dependency enhances or adds.
And while we're swiping stuff from Debian, how about something like debconf...
On Thu, 27 Apr 2006, Callum Lerwick wrote:
On Thu, 2006-04-27 at 14:05 +0930, n0dalus wrote:
The problem is that there's not a good way yet of giving packages 'Suggests'/'Enhances' tags. At the moment all we provide are packages with either 'Requires' or nothing. The idea would be that the package manager would ask the user which suggests/enhances to install (with suggests selected by default).
Which is something Debian packages support. Meh, I've always figured RPM systems seem to get along okay without it, and most of all on my Debian systems I never find myself actually using or caring about Suggests / Recommends anyway, but I guess it's not a horrible idea. What would be nice if we're going to do it is a human friendly short %description as to what exactly each optional dependency enhances or adds.
Recent rpm versions support soft dependencies, eg Requires(hint): foo Provides(hint): bar
..and have corresponding "aliases" for spec file syntax: Suggests: foo Enhances: bar
Too bad it doesn't seem like we're getting a version of rpm supporting those anytime soon :-/
- Panu -
On Thu, April 27, 2006 9:50 am, Panu Matilainen said:
Too bad it doesn't seem like we're getting a version of rpm supporting those anytime soon :-/
Why is that BTW?
On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote:
Recent rpm versions support soft dependencies, eg Requires(hint): foo Provides(hint): bar
..and have corresponding "aliases" for spec file syntax: Suggests: foo Enhances: bar
How is this supposed to work an an automated installation?
On Thu, 2006-04-27 at 10:29 -0400, Jesse Keating wrote:
On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote:
Recent rpm versions support soft dependencies, eg Requires(hint): foo Provides(hint): bar
..and have corresponding "aliases" for spec file syntax: Suggests: foo Enhances: bar
How is this supposed to work an an automated installation?
You either don't install soft dependencies or install them all, the latter hardly being a sane option.
One would probably want two levels of soft requires - the syntax is implemented in rpm but not sure if they're currently distinguishable outside the spec syntax: Requires(missingok) and Requires(hint) where "missingok" is something you'd want to install by default but removing of the dependency wont break the package, "hint" being .. well, a hint that this might be useful with this software but not installed automatically. Enhances is basically Suggests reversed for situations where Suggests cannot be used because the main package has no knowledge of the enhancing package.
- Panu -
On Thu, 2006-04-27 at 18:13 +0300, Panu Matilainen wrote:
One would probably want two levels of soft requires - the syntax is implemented in rpm but not sure if they're currently distinguishable outside the spec syntax: Requires(missingok) and Requires(hint) where "missingok" is something you'd want to install by default but removing of the dependency wont break the package, "hint" being .. well, a hint that this might be useful with this software but not installed automatically. Enhances is basically Suggests reversed for situations where Suggests cannot be used because the main package has no knowledge of the enhancing package.
This seems to be spiraling into major complexity and lots of ways for developers to get it wrong. Boo. I've never been very thrilled with the idea of soft deps, and I really haven't seen it done right.
On 4/28/06, Jesse Keating jkeating@j2solutions.net wrote:
This seems to be spiraling into major complexity and lots of ways for developers to get it wrong. Boo. I've never been very thrilled with the idea of soft deps, and I really haven't seen it done right.
If the developers can't grasp the concept of a 3 level requires/suggests/enhances, they can just use the normal one level 'requires' and nobody will get hurt. The implementation of 'soft deps' as you call them is not really for rpm(8) anyway, it's for package managers. If you don't like the way it's been done so far, then make sure whatever package manager you use implements it correctly. If for you that means simply treating suggestions as requires and ignoring enhances (as is more or less the current way of setting package requirements in Fedora), then so be it -- don't complain that the functionality is there for those who want to use it.
My 2c, n0dalus.
On Thu, 27 Apr 2006, Jesse Keating wrote:
On Thu, 2006-04-27 at 18:13 +0300, Panu Matilainen wrote:
One would probably want two levels of soft requires - the syntax is implemented in rpm but not sure if they're currently distinguishable outside the spec syntax: Requires(missingok) and Requires(hint) where "missingok" is something you'd want to install by default but removing of the dependency wont break the package, "hint" being .. well, a hint that this might be useful with this software but not installed automatically. Enhances is basically Suggests reversed for situations where Suggests cannot be used because the main package has no knowledge of the enhancing package.
This seems to be spiraling into major complexity and lots of ways for developers to get it wrong. Boo. I've never been very thrilled with the idea of soft deps, and I really haven't seen it done right.
What's so difficult about this:
1) It's hard dependency, without it the package will not run. 2) It's something that should be installed for "best user experience" but the package will run without it. Depsolvers treat it as any old hard dependency expect dont whine about it if it's removed. A good example of this would be evolution requiring spamassassin - evo will work just fine without spamassassin and in many environments the spamassassin is completely redundant to have on every workstation. 3) It's something that will bring in additional functionality useful for some users. Nothing more than a hint that a depsolver (GUI) might list "you might additionally find some of these useful". An example of this would be xmms + it's myriad of plugins: xmms-sid isn't something most people will care about.
- Panu -
On Fri, Apr 28, 2006 at 02:16:59AM -0700, Panu Matilainen wrote:
- It's something that will bring in additional functionality useful for some users. Nothing more than a hint that a depsolver (GUI) might list "you might additionally find some of these useful". An example of this would be xmms + it's myriad of plugins: xmms-sid isn't something most people will care about.
Stupid question, but how hard would it be for a depsolver to work this out in reverse? For example, xmms-sid requires xmms, so when I'm installing xmms, notice that xmms-sid requires it, and suggest it as a possible enhancement?
I could see something like that being *really* handy with perl-Kwiki and the dozen or so plugins that are available in Extras right now. It would suck if I had to modify the main perl-Kwiki package every time someone packages up another plugin. (That is, of course, assuming that someone other than me packages some plugins... ;)
Steve
On Fri, 2006-04-28 at 08:43 -0500, Steven Pritchard wrote:
On Fri, Apr 28, 2006 at 02:16:59AM -0700, Panu Matilainen wrote:
- It's something that will bring in additional functionality useful for some users. Nothing more than a hint that a depsolver (GUI) might list "you might additionally find some of these useful". An example of this would be xmms + it's myriad of plugins: xmms-sid isn't something most people will care about.
Stupid question, but how hard would it be for a depsolver to work this out in reverse? For example, xmms-sid requires xmms, so when I'm installing xmms, notice that xmms-sid requires it, and suggest it as a possible enhancement?
I've thought about this - getting the reverse dependencies is not hard at all, basically the depsolver could do the equivalent of this:
[root@weasel ~]# repoquery --whatrequires --alldeps perl-Kwiki perl-Kwiki-Attachments-0:0.18-1.fc5.noarch perl-Kwiki-UserName-0:0.14-3.fc5.noarch perl-Kwiki-NewPage-0:0.12-3.fc5.noarch perl-Kwiki-ModPerl-0:0.09-2.fc5.noarch perl-Kwiki-Search-0:0.12-3.fc5.noarch perl-Kwiki-Archive-Rcs-0:0.15-4.fc5.noarch perl-Kwiki-Revisions-0:0.15-3.fc5.noarch perl-Kwiki-Raw-0:0.02-2.fc5.noarch perl-Kwiki-0:0.38-3.fc5.noarch perl-Kwiki-UserPreferences-0:0.13-3.fc5.noarch perl-Kwiki-Diff-0:0.03-2.fc5.noarch perl-Kwiki-Users-Remote-0:0.04-2.fc5.noarch perl-Kwiki-RecentChanges-0:0.13-3.fc5.noarch
What's problematic with this approach is that it only works for certain types of packages, something resembling an application in other words. Try it on a library and the results are probably not what you want.
If there was a good way to distinguish application vs pure library packages that might well be sufficient as a suggests/enhances mechanism. Unfortunately it's not that clear. Taking perl-Kwiki as an example, it lists "Development/Libraries" as it's rpm group, it doesn't belong to any comps groups and it doesn't look like an application in the sense that it doesn't put anything into your path (which is a very bad heuristics anyway since many library packages have some utility binaries) etc. It'd be very likely to be classified as a library of sorts by any obvious heuristics to determine whether "suggests/enhances"-reverse depends logic should be applied.
I could see something like that being *really* handy with perl-Kwiki and the dozen or so plugins that are available in Extras right now. It would suck if I had to modify the main perl-Kwiki package every time someone packages up another plugin. (That is, of course, assuming that someone other than me packages some plugins... ;)
That's what Enhances is all about: the main package wouldn't have to be aware of those other packages, those plugin packages would just have to add "Enhances: perl-Kwiki".
- Panu -
On Fri, Apr 28, 2006 at 05:50:21PM +0300, Panu Matilainen wrote:
On Fri, 2006-04-28 at 08:43 -0500, Steven Pritchard wrote:
Stupid question, but how hard would it be for a depsolver to work this out in reverse? For example, xmms-sid requires xmms, so when I'm installing xmms, notice that xmms-sid requires it, and suggest it as a possible enhancement?
I've thought about this - getting the reverse dependencies is not hard at all, basically the depsolver could do the equivalent of this:
[root@weasel ~]# repoquery --whatrequires --alldeps perl-Kwiki
[...]
What's problematic with this approach is that it only works for certain types of packages, something resembling an application in other words. Try it on a library and the results are probably not what you want.
So how would you fix that? Walk through all the file provides/requires and all the other implicit dependencies? And if you did all that, how painful would it be? :-)
Taking perl-Kwiki as an example, it lists "Development/Libraries" as it's rpm group,
That's because cpanspec is hard-coded to add that Group: tag.
it doesn't belong to any comps groups
That's because I haven't added any of my packages to comps. (Shame on me, I know, it's on my todo list.)
and it doesn't look like an application in the sense that it doesn't put anything into your path
There's just the "kwiki" script in /usr/bin/...
(which is a very bad heuristics anyway since many library packages have some utility binaries) etc. It'd be very likely to be classified as a library of sorts by any obvious heuristics to determine whether "suggests/enhances"-reverse depends logic should be applied.
Even having this available as a convoluted command involving repoquery would be pretty cool. :-)
That's what Enhances is all about: the main package wouldn't have to be aware of those other packages, those plugin packages would just have to add "Enhances: perl-Kwiki".
Ah, my sleep-deprived mind was reading that backwards. That makes a whole lot more sense. ;-)
Steve
On Thu, 2006-04-27 at 11:24 -0400, Jesse Keating wrote:
This seems to be spiraling into major complexity and lots of ways for developers to get it wrong. Boo. I've never been very thrilled with the idea of soft deps, and I really haven't seen it done right.
I like them. I'm sure they can be abused, but for example -
perl-Readonly)
It's a perl module (am I observant or what?? ;) Anyway - applications that use it will require perl(Readonly)
perl-Readonly gets a performance boost from perl(Readonly::XS) but does not explicitly require it.
That is a case where using a soft dependency will help. A perl program requires perl(Readonly) which suggests perl(Readonly::XS).
perl(Readonly) is pure perl, noarch. perl(Readonly::XS) is a binary. If there were a problem building the binary on one or more platform, it might not be available, so we don't want to have it be required by perl-Readonly. A suggest though we _do_ want.
We also can't have perl(Readonly::XS) required by the perl-Readonly rpm because that causes a circular dependency at build time - as perl-Readonly-XS requires perl(Readonly) to build. But a suggest - the build machine could (should) ignore suggests.
That's why it is a good thing to have suggests.
On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote:
Recent rpm versions support soft dependencies, eg Requires(hint): foo Provides(hint): bar
..and have corresponding "aliases" for spec file syntax: Suggests: foo Enhances: bar
Too bad it doesn't seem like we're getting a version of rpm supporting those anytime soon :-/
I was told on the rpm list by an rpm developer that it would probably be at least a year before repository front ends properly supported those new features anyway - so if I used them, don't expect them to do what I want in repositories for awhile.
On 4/27/06, Callum Lerwick seg@haxxed.com wrote:
Grasping at straws, eh? If firefox supports mathml and needs mathml-fonts to display properly, then perhaps firefox should be depending on mathml-fonts. Or at least putting up some kind of message like "This page cannot be displayed properly, you need mathml-fonts".
"need" and "optional" are distinct concepts. The point he's trying to make is that a package which is a hard package requirement may in fact be useful in other context than those explicitly encoded by the limited range of relationships which can be encoded in an rpm package. Just because a user did not explictly request a particular package when installing something else does not mean that the dependacy does not itself have value to the user.
By automatically removing things that were not placed on the system explicitly, with no other attempts to check as to whether the files in those packages are being used outside the bounds of the strict "requires" packaging dependancy relationship, all you end up doing is creating situations where users have to go back and explicitly reinstall those items... a pointless waste of time which puts more demands on the user to know exactly which package does what.
Automatic removal of dependancies can not be done without human review as to which of those packages are still locally needed, and I think its far more appropriate to expect users who want to clean up their system to do that review before items are removed than it is to automatically remove deps and expect users to review which items should be put back on the system to keep the functionality they expect.
-jef"look on the side of the road, a dead horse! Let's go over there and beat it!"spaleta
On Thu, 2006-04-27 at 00:38 -0400, Jeff Spaleta wrote:
Automatic removal of dependancies can not be done without human review as to which of those packages are still locally needed, and I think its far more appropriate to expect users who want to clean up their system to do that review before items are removed than it is to automatically remove deps and expect users to review which items should be put back on the system to keep the functionality they expect.
Now we're just splitting hairs about what "automatic removal" means.
Yes, review is good. aptitude has a nice transaction preview screen, giving you a chance to review everything its going to do, and won't perform a transaction without showing it first.
-jef"look on the side of the road, a dead horse! Let's go over there and beat it!"spaleta
*whap* *whap* *whap* *thunk*
On 4/27/06, Callum Lerwick seg@haxxed.com wrote:
Now we're just splitting hairs about what "automatic removal" means.
No I'm not... let me be as clear. Any mechanism that allows people to dialog their way through removals of non-explictly installed deps, that does not try to accurately account for file access outside the context of the strictly defined package management relationship will undoubtable mislead novice users into removing packages that provide functionality that they were in fact depending on. For users who know enough to know whether they(or scripts/applications on their system) are not in fact using a particular package.. those more advanced users can very easily create a list of "leaves" from something like package-cleanup and then review, per package, whether the package provides needed functionality or not.
Any attempt to provide an application which makes it any easier to remove a collection of packages solely use information with regard to 'explicit' installation of a package will ultimately lead to numerous unexpected, untested and hard to reproduce problems for the very class of users who do not have the skills or the experience to troubleshoot a loss of functionality after-the-fact. And I have no doubt that the 3% of the population who know enough about their systems and their packages to be able to use such an "automated" removal feature in an infromed manner would find it a convient feature... because they are human and they are lazy bastards. But I dare say that its not worth making such an application widely available, or easily accessible, nor a "core" part of the distribution because it will lead the other 97% of the userbase who do not know enough about packaging into situations where the tool removes functionality they were using.
Yes, review is good. aptitude has a nice transaction preview screen, giving you a chance to review everything its going to do, and won't perform a transaction without showing it first.
You keep pimping aptitude like its a solution to the underlying problem. It isn't. I'm quite sure that aptitude or something like it is very handy for people who know what they are doing. For novice users, I think such a set of tools will in fact cause an unacceptable amount problems if the tools make no effort to make additional tests such as file access which attempt to account for usage of the packages which fall outside the strictly defined package mangement relationships. Since aptitude's interactivity/review give no information as to out of package manager file access... a novice user is given no information which can be used to warn them that the packages in the list to be removed are in fact being used by something the packager didn't expect. Aptitude or similar tool requires its users to have a keen understanding of how packages are being used on their own. And that sort of assumption is absolutely inappropriate for a tool which people want to expose as a generally available feature exposed to the entire fedora userbase.
I really really hope the Ubuntu people figure out a way to track out of package manager context file access which can account for prelink activity as the integrate the feature into their desktop oriented distro, ( which was what started this hellaish thread of the damned). I dare say the demographics of the Ubuntu userbase are not well correlated with the debian userbase, so whatever the typically experience is with aptitude in debian will not automatically be the typical experience with a similiar tool in Ubuntu. Babies will be eaten, and this time it won't be my fault.
-jef"Isn't it enough to know that I ruined a pony making a gift for you? --Jonathan Coulton"spaleta
On Thu, 2006-04-27 at 02:45 -0400, Jeff Spaleta wrote
I don't know why you keep flogging the newbie angle. There's a reason I recommended this functionality go into yumex, or simply remain in aptitude, and not yum itself or pup or pirut or whatever.
On Thu, Apr 27, 2006 at 02:45:19AM -0400, Jeff Spaleta wrote:
You keep pimping aptitude like its a solution to the underlying problem. It isn't. I'm quite sure that aptitude or something like it is very handy for people who know what they are doing. For novice users, I think such a set of tools will in fact cause an unacceptable amount problems if the tools make no effort to make additional tests such as file access which attempt to account for usage of the packages which fall outside the strictly defined package mangement relationships. Since aptitude's interactivity/review give no information as to out of package manager file access... a novice user is given no information which can be used to warn them that the packages in the list to be removed are in fact being used by something the packager didn't expect. Aptitude or similar tool requires its users to have a keen understanding of how packages are being used on their own. And that sort of assumption is absolutely inappropriate for a tool which people want to expose as a generally available feature exposed to the entire fedora userbase.
I don't know what aptitude you are familiar with, but apparently it isn't the same one I've used on a daily basis for six years or so. It's an excellent front end to dpkg, which new users seem to use as well. It's a shame you're so dismissive of it.
Really, when's the last time you used aptitude?
I really really hope the Ubuntu people figure out a way to track out of package manager context file access which can account for prelink activity as the integrate the feature into their desktop oriented distro
<sigh> Ubuntu huh? If it is "the Ubuntu peopel" odds are it will be a DD that Shuttleworth paid for.
D
On Thu, 2006-04-27 at 20:31 +0100, ded wrote:
I don't know what aptitude you are familiar with, but apparently it isn't the same one I've used on a daily basis for six years or so. It's an excellent front end to dpkg, which new users seem to use as well. It's a shame you're so dismissive of it.
Fedora lesson #1: Jeff's job is to dismiss any and every idea that comes up. :)
Some loyal dissension is good for keeping everyone honest and grounded, but past a certain point its just plain stubbornness...
On Thu, Apr 27, 2006 at 02:50:54PM -0500, Callum Lerwick wrote:
On Thu, 2006-04-27 at 20:31 +0100, ded wrote:
I don't know what aptitude you are familiar with, but apparently it isn't the same one I've used on a daily basis for six years or so. It's an excellent front end to dpkg, which new users seem to use as well. It's a shame you're so dismissive of it.
Fedora lesson #1: Jeff's job is to dismiss any and every idea that comes up. :)
Some loyal dissension is good for keeping everyone honest and grounded, but past a certain point its just plain stubbornness...
Point taken :)
Kind Regards, D
On Wed, 2006-04-26 at 23:24 -0500, Callum Lerwick wrote:
On Tue, 2006-04-25 at 22:37 -0700, Michael A. Peters wrote:
That assumes that the end user knows what a package is and what it does. Say I had no clue that mathml-fonts were needed to properly view the blog of my Physics professor. I might not even know what mathml is. It just works because something else pulled them in as a dependency.
Grasping at straws, eh? If firefox supports mathml and needs mathml-fonts to display properly, then perhaps firefox should be depending on mathml-fonts. Or at least putting up some kind of message like "This page cannot be displayed properly, you need mathml-fonts".
Firefox does notify the user that they are missing fonts. It then directs them to instructions (if I remember) that are a sub-optimal way of installing them on a system that already has the packaged.
The point is that there will be software users have need for that they don't necessarily know they have a need for.
On Tuesday 25 April 2006 07:19am, Michael A. Peters wrote:
On Sat, 2006-04-22 at 00:50 +0100, Leon wrote:
I think you didn't get the idea right.
Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence.
Ubuntu put this *high* priority for the next release after dapper. After reading its wiki page, it make sense to me. And I believe it will be useful.
I want the mathml-fonts fonts installed. I know that "yum install abiword" which I also want will grab them as a dependency.
But suppose I decide that I'm not using AbiWord anymore because I'm doing everything in LaTeX. So I remove AbiWord.
mathml-fonts I still want though - but it was installed as a dependency to abiword, which I have since removed.
Does that mean mathml-fonts will get automatically removed out from under me?
That's why I never never run "yum -y remove splat" ("yum -y install splat" for that matter).
In such a situation, it would be very nice to be able to selectively "uncheck" packages from the dependency list that were automatically selected for removal, too. But that's probably best handled by the GUI if you want it to be interactive. On the command line (i.e., just the yum command), I would say "n" to removing the packages, yum exits, I press the Up Arrow key and edit the line to read "yum --exclude=mathml-fonts remove splat".
Then again, I don't believe that any application package should "depend" on font packages, in general. However, it the automatic removal selection mechanism is added to yum, it should be possible to mark "soft" dependencies in an RPM (like an Include: directive, for example) that says, "Hey, it's good to also include that package when you install this one."
Of course, I just opened a very XL can-o-worms there, didn't I?
Just to be clear, though, I'm for the idea of automatic dependency resolution for removal. If nothing else depends on a package once those items that did are removed, why keep the clutter around? I know disk space is _really_ cheap, but I still like to keep my systems tidy.
On Fri, 2006-04-21 at 19:08 -0400, Jeff Spaleta wrote:
automatic upgrading of dependancies.. will only work if all applications
^^^^^^^^^
and scripts on the system are managed by the package management system. That means that nothing on the system can be installed via source which makes it outside the scope of the package management system which may be using an "indirect" dependancy.
Fixed.
All,
Here are a couple of suggestions of how add auto-no-longer-used-dependency removal to yum.
1. Enhance RPM to track a new flag from each package to indicate whether or not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages.
2. Take what we have with "yum deplist" and create a new command ("removedeps" ?) that automatically adds those packages that are no longer depended on by anything else that is installed, to the list of packages to remove.
3. Same as 2, but integrate the ability into the existing "yum remove" command. When packages are found that qualify for auto-inclusion-for-removal, list them and make the question take 3 possible answers: y/a/N (yes, auto/all, no). If you pick "a", then you get the whole smash. If you pick "y", you get the exact same behavior we have today and you do not remove those auto-no-longer-used-dependency packages. If you pick "n" (the default if you hit enter), you get the same behavior we have today, which is to bail out.
Comments?
On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote:
All,
Here are a couple of suggestions of how add auto-no-longer-used-dependency removal to yum.
- Enhance RPM to track a new flag from each package to indicate whether or
not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages.
- Take what we have with "yum deplist" and create a new command
("removedeps" ?) that automatically adds those packages that are no longer depended on by anything else that is installed, to the list of packages to remove.
- Same as 2, but integrate the ability into the existing "yum remove"
command. When packages are found that qualify for auto-inclusion-for-removal, list them and make the question take 3 possible answers: y/a/N (yes, auto/all, no). If you pick "a", then you get the whole smash. If you pick "y", you get the exact same behavior we have today and you do not remove those auto-no-longer-used-dependency packages. If you pick "n" (the default if you hit enter), you get the same behavior we have today, which is to bail out.
You could do #3 or #2 as a plugin if you'd like to try it.
I think #1 is unlikely to happen. -sv
On Thursday 27 April 2006 12:52pm, seth vidal wrote:
On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote:
All,
Here are a couple of suggestions of how add auto-no-longer-used-dependency removal to yum.
- Enhance RPM to track a new flag from each package to indicate whether
or not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages.
- Take what we have with "yum deplist" and create a new command
("removedeps" ?) that automatically adds those packages that are no longer depended on by anything else that is installed, to the list of packages to remove.
- Same as 2, but integrate the ability into the existing "yum remove"
command. When packages are found that qualify for auto-inclusion-for-removal, list them and make the question take 3 possible answers: y/a/N (yes, auto/all, no). If you pick "a", then you get the whole smash. If you pick "y", you get the exact same behavior we have today and you do not remove those auto-no-longer-used-dependency packages. If you pick "n" (the default if you hit enter), you get the same behavior we have today, which is to bail out.
You could do #3 or #2 as a plugin if you'd like to try it.
I think I'll take a crack at it.
I think #1 is unlikely to happen.
I agree. I only included it for completeness sake, since it was obvious. However, #1 does have the advantage of taking place at the RPM DB level, and thus being available to anything built atop the RPM libs, though, it would still require awareness in the higher level apps (like yum) to make it useable.
On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote:
- Enhance RPM to track a new flag from each package to indicate whether or
not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages.
In the long term, if such functionality becomes common, it would be nice to have RPM allow a flag to be stored within the package database, so that multiple front ends can share it.
As is, aptitude tracks it in its own database. (Even on its native Debian) Which means any packages installed outside aptitude are assumed to be explicit installs.
For now, just track it in the front end, and help prove its useful and desirable functionality. :)
On Thursday 27 April 2006 01:16pm, Callum Lerwick wrote:
On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote:
- Enhance RPM to track a new flag from each package to indicate whether
or not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages.
In the long term, if such functionality becomes common, it would be nice to have RPM allow a flag to be stored within the package database, so that multiple front ends can share it.
That's what I meant, for the flag to be stored in the RPM DB. Sorry for not being clear about that.
[snip]
On Thu, 2006-04-27 at 13:27 -0600, Lamont R. Peterson wrote:
That's what I meant, for the flag to be stored in the RPM DB. Sorry for not being clear about that.
S'okay. I just feel its necessary to stress the point that at most, all we expect RPM itself to do, is store a single measly flag per installed package...
"LRP" == Lamont R Peterson lamont@gurulabs.com writes:
LRP> All, Here are a couple of suggestions of how add LRP> auto-no-longer-used-dependency removal to yum.
LRP> 1. Enhance RPM to track a new flag from each package to indicate LRP> whether or not it was installed auto-selected-for-dependency. LRP> Then, "yum remove foo" could automatically select to remove all LRP> packages that "foo" depends on that are no longer depended on by LRP> any other installed packages.
How about simply adding a flag to rpm packages, saying that they are useless for anything except as dependencies? Most libraries would fit that.
It would be yet another thing for package maintainers to get right, of course.
/Benny
On Thu, Apr 27, 2006 at 10:16:59PM +0200, Benny Amorsen wrote:
How about simply adding a flag to rpm packages, saying that they are useless for anything except as dependencies? Most libraries would fit that.
If you want to go this [*] route, why have a flag? Just make your yum plug in consider all packages which only install things into /lib and/or /usr/lib + optionally docs.
It would be yet another thing for package maintainers to get right, of course.
Presto, there's that problem solved. :)
[*] crazy, if you ask me, but no one did
On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote:
All,
Here are a couple of suggestions of how add auto-no-longer-used-dependency removal to yum.
- Enhance RPM to track a new flag from each package to indicate whether or
not it was installed auto-selected-for-dependency.
How do you plan on discovering this data? During installation, basically everything is the latter, or equivalent, except for packages selected individually in a ks.cfg .
Peter Jones <pjones <at> redhat.com> writes:
How do you plan on discovering this data? During installation, basically everything is the latter, or equivalent, except for packages selected individually in a ks.cfg .
Well, I'd say (for an interactive install) everything with a checkmark next to it (no matter whether that's because it's part of defaults of a selected group and hasn't been unchecked or because it has been checked explicitly) is "explicitly installed". Everything else (which either is not listed as an explicit option at all or was unchecked, but had to be pulled in anyway as a dependency) is "automatically installed".
(Of course, that requires cooperation from the installer and from RPM. If the flags are kept track of only by some higher-level app like aptitude, then marking everything installed at install time "explicitly installed" is the only option, and apparently that's what aptitude does.)
Kevin Kofler
On Fri, 2006-04-28 at 15:43 +0000, Kevin Kofler wrote:
Peter Jones <pjones <at> redhat.com> writes:
How do you plan on discovering this data? During installation, basically everything is the latter, or equivalent, except for packages selected individually in a ks.cfg .
Well, I'd say (for an interactive install) everything with a checkmark next to it (no matter whether that's because it's part of defaults of a selected group and hasn't been unchecked or because it has been checked explicitly) is "explicitly installed". Everything else (which either is not listed as an explicit option at all or was unchecked, but had to be pulled in anyway as a dependency) is "automatically installed".
So that basically means that you want to mark everything which is listed in comps but isn't in "base" or "core" as user-installed. That's going to result in a view of "safe to remove" that doesn't reflect what users want or expect.
(Of course, that requires cooperation from the installer and from RPM. If the flags are kept track of only by some higher-level app like aptitude, then marking everything installed at install time "explicitly installed" is the only option, and apparently that's what aptitude does.)
I think that's the only way to actually behave conservatively enough to match user expectations. I also think it stinks.
Peter Jones <pjones <at> redhat.com> writes:
So that basically means that you want to mark everything which is listed in comps but isn't in "base" or "core" as user-installed. That's going to result in a view of "safe to remove" that doesn't reflect what users want or expect.
So maybe special-case "base" and "core"? Let's mark those packages "explicitly installed" (or maybe "essential", but from my past experience with apt-rpm, that doesn't work too well if you can have more than one version installed, such as for kernels: you get a scary warning if you remove an old kernel, but that could probably be fixed in apt (it should warn only if you remove all versions of the essential package) and yum could get it right right away). But a package which is not a base/core package nor has been checked explicitly is by definition "automatically installed for dependencies".
Kevin Kofler
devel@lists.stg.fedoraproject.org
-
Arthur Pemberton -
Benny Amorsen -
Callum Lerwick -
Dan -
Dimi Paun -
Ed Marshall -
Horst H. von Brand -
Jef Spaleta -
Jesse Keating -
John Thacker -
Kevin Kofler -
Lamont R. Peterson -
Leo -
Mark Rosenstand -
Matthew Miller -
Michael A. Peters -
n0dalus -
Ola Thoresen -
Panu Matilainen -
Peter Jones -
Pádraig Brady -
Ralf Ertzinger -
seth vidal -
Steven Pritchard