sudo packages requires vim-minimal

[MartinPedersen]

I had both vim-minimal and vim-enhanced installed.
Removing vim-minimal and yum/fedora 19 also wants to remove sudo. It is probably because of visudo.

$ rpm -q --requires sudo | grep vim
vim-minimal

Suggests:

1. Remove this requirement because visudo can use any CLI editor eg.
   EDITOR=nano visudo
   or
2. Make a abstract package vim which contains both vim-enhanced and vim-minimal and make the
   abstract package a requirement for sudo.

$ sudo yum remove vim-minimal
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
-> Package vim-minimal.x86_64 2:7.3.944-1.fc19 will be erased
--> Processing Dependency: vim-minimal for package: sudo-1.8.6p7-1.fc19.x86_64
--> Running transaction check
-> Package sudo.x86_64 0:1.8.6p7-1.fc19 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

==================================================================================================================
 Package                    Arch                  Version                          Repository                Size
==================================================================================================================
Removing:
 vim-minimal                x86_64                2:7.3.944-1.fc19                @fedora                 794 k
Removing for dependencies:
 sudo                       x86_64                1.8.6p7-1.fc19                  @anaconda               2.4 M

[smr54]

Most distributions are pretty bad this way, throwing in unnecessary dependencies, (and often leaving necessary ones out because the developer, for example, may have only tested with Gnome, not realizing that something necessary was provided by Gnome).

I would first check it by doing something like rpm -e --nodeps vim-minimal. This would remove vim-minimal without removing sudo. Then check if you can definitely use sudo. (Sometimes, something is a dependency because program a provides library b that is needed by program c.)

Debian based distributions have nano as their default editor, so running visudo opens up nano, therefore the chances are that you're correct about vim-minimal being unnecessary.

Once you've confirmed that, you can file a bug report. Mentioning it here has no real effect--this forum is just users helping other users, and while some developers may glance over it, if they caught this post, their suggestion would be to file a bug at
bugzilla.redhat.com (which requires registration.)

See http://www.forums.fedoraforum.org/sh...d.php?t=224980

[MartinPedersen]

Thanks.

I forgot to mention that I actually already just removed the vim-minimal with

rpm -e --no-deps vim-minimal

and sudo and visudo works without problems.

Thank you for the link to bugzilla. I will fill a report.

[MartinPedersen]

I found a bug report on this already but a developer didn't think this a bug.
Strange world.

https://bugzilla.redhat.com/show_bug.cgi?id=164982

[smr54]

It's one of those things that isn't going to affect very many users. The developer sounds short tempered. Of course, if you do remove vim-minimal and then update sudo, it will probably pull in vim-minimal again.

Personally, I'd put it under the category of minor aggravations. If you really felt like doing something about it, I suspect you could download the srpm and rebuild it, removing the dependency for vim-minimal. It depends upon how much effort you feel like putting into it.

Note that that bug is from 2005, so it's conceivable that it's a different packager now, who might be more willing to consider it.
If you did file it, I'd refer to that 2005 bug and just politely ask them to reconsider.

[vallimar]

ENVIRONMENT
The following environment variables may be consulted depending on the
value of the editor and env_editor sudoers settings:

VISUAL Invoked by visudo as the editor to use

EDITOR Used by visudo if VISUAL is not set

One solution is if all the different text-editors had a "Provides: text-editor" bit for packages
like this to do a "Requires: text-editor" instead of a hard dependency on a named package.
Then it wouldn't matter if you had nano, vim-minimal, vim-enhanced or whatever and there
was a profile script to set a default VISUAL and EDITOR variable based on a preferred if-else
check. Or they could use the alternatives system too with a generic symlink. They have been
doing it more with other things, so maybe with some prompting they can get around to doing
it for this as well.

[AdamW]

alternatives is horrible and we want to use it as little as possible. a generic virtual provide for 'text-editor' would be more interesting, though it's hard to get the details of such a policy right.

"Most distributions are pretty bad this way, throwing in unnecessary dependencies"

This is really an over-simplification of a complex question. Where do you draw the line between a 'necessary' and 'unnecessary' dependency? If an app will run without package foo, but won't do the thing 99% of its users expect it to do without package foo, is foo a dependency? 95%? 90%? If an app is prone to breaking without a given package unless you do a manual configuration change (as is the case here), is the package a dependency? These are not straightforward questions.

On the bug report for vim-minimal vs. vim-enhanced, as the packager says, it doesn't make sense to accept vim-enhanced as 'satisfying' the dependency:

"The "/bin/vi" is default sudo editor for the visudo util."

[adamw@adam Pictures]$ sudo repoquery -l vim-enhanced
/etc/profile.d/vim.csh
/etc/profile.d/vim.sh
/usr/bin/rvim
/usr/bin/vim
/usr/bin/vimdiff
/usr/bin/vimtutor

vim-enhanced contains no 'vi'.

[smr54]

This is one of the rare instances where I have to disagree with Adam. Although, in fairness, I don't know that any of us really know what 99 percent of the users expect, and I do know that Adam makes great effort to see what the community wants.

[AdamW]

This is one of the rare instances where I have to disagree with Adam. Although, in fairness, I don't know that any of us really know what 99 percent of the users expect, and I do know that Adam makes great effort to see what the community wants.

Well, disagree with me how? Which bit of what I wrote do you disagree with? Do you think defining what should and should not be Require: d by a package is a straightforward thing with a simple definition? If so, what is it?

[smr54]

What, you want specifics? I'm much happier making broad generalizations.
One example (and I'm not on Fedora right this moment, so can't even check if it's actually still true), why would samba pull in cups?

In fairness, again, I can't say that any of them are clear cut decisions. Debian has its recommended thing, which helps cut down bloat, and Arch has a nice thing where after installation, they'll recommend some other packages, if the user wants it.

To change over to something like that, at this point, would obviously be an enormous amount of work. (That is, to change some things from being required to recommended--and then changing yum or rpm to use some sort of flag to honor that.)

In my opinion, and this is of course, only my opinion, I'd rather see things only have what is necessary for them to function. That is, if cups was a dependency of samba, (an untested example, going by vague memory) _I_ feel it should be removed.

BIG DISCLAIMER--let me reiterate that I'm not even sure cups is a dependency of samba.

I will freely agree that you are right in that it is not always a clear decision. For example, I've had to file bugzillas about a few packages where things that _I_ needed were left out.

(IIRC, in both cases, the maintainer agreed that I was right and the added dependencies should be added in)

[AdamW]

I personally would actually like to have a soft-dependency mechanism in Fedora; Mandriva has one and I liked having that around. It wouldn't be that much work - the patches for it exist (in "rpm5" and MDV and SUSE) and it's not like you have to have some kind of big planned Single Switch Over to soft deps, you can just let packagers use them at their discretion.

But there are some reasonable arguments against soft deps - they can be abused as a chicken-out way of handling situations that can really be handled better, and there are various corner cases with them that are very hard for the package manager to resolve. I still overall would prefer to have them, but I understand the argument against.

On my system, samba does not appear to depend on cups. 'yum remove cups' does not want to remove any samba-related packages, only stuff you'd naturally expect (printing-related bits).

[vallimar]

alternatives is horrible and we want to use it as little as possible. a generic virtual provide for 'text-editor' would be more interesting, though it's hard to get the details of such a policy right.

I completely agree about alternatives. The script solution I had in mind was like the old X11
prefdm script, where it checked for a user variable first, then for gdm/kdm/fvwm and just
load xterm as a last resort.

With samba, you can remove cups, but you cannot remove cups-libs. This is one of the
most annoying things about linux, a serious lack of dynamic/pluggable linkage. Soft-deps,
suggestions and whatnot for rpm's can't fix hard-dependencies between libraries.

For instance, I have no use for a wacom tablet, never will.. I'm sure many other Fedora
users never will either, yet anyone using gnome is stuck with it and many other should-
be-optional bits. Until this base flaw gets resolved, there is only so much the Fedora folks
can do to limit dependencies while also providing the features the majority (may) want,
and breaking packages apart is part of what they have done to alleviate unneeded bloat.

Realistically, things like needing libwacom, cups-libs or even vim-minimal, the packages
are small enough and don't interfere with anything otherwise that it really is best to just
suck it up (or learn to compile your own packages).

[smr54]

Just booted up a fairly minimal Fedora install and cups doesn't install samba either. I see it does install bc, which doesn't seem as if it should be a dependency. <shrug>. I wonder if one was a dependency of the other at some point, or if I'm just totally confused, which is more likely.

At any rate, I like that soft dependency idea, but for me at least, it's less important as I've learned to minimize my installs.

[DBelton]

I really don't know what a good solution to the dependency issue could possibly be. I usually end up tossing packages in the trash when they start pulling in things I don't like. For example, when the libreport gui package started pulling in jack audio demos and recordmydesktop, it went in the trash along with abrt gui which pulled in libreport gui.

Seems like my list of packages I remove from a fresh install is getting longer

[AdamW]

the reason libreport does that is so you can record a screencast of a bug and attach it if that would be useful to explain it to the maintainer. Seems pretty useful. I think there's been some discussion of whether we could do that in a modular way rather than just having a dependency in libreport, though.