does mc really require perl*?

[Felix Miata]

I did a TC5 minimal install last night, which omitted mc, my most used 
cmdline tool. So:

# yum install mc
... installing for dependencies:
gpm-libs (which I never ever use)
perl* (29 packages)...

Seriously? What does mc need perl for?

I installed mc plus gpm-libs with rpm --nodeps, and it works.

[Dan Horák]

On Mon, 09 Sep 2013 20:27:09 -0400
Felix Miata  wrote:
> I did a TC5 minimal install last night, which omitted mc, my most
> used cmdline tool. So:
>
> # yum install mc
> ... installing for dependencies:
> gpm-libs (which I never ever use)
> perl* (29 packages)...
>
> Seriously? What does mc need perl for?

see /usr/libexec/mc/extfs.d

Dan
> I installed mc plus gpm-libs with rpm --nodeps, and it works.
>
> "The wise are known for their understanding, and pleasant
> words are persuasive." Proverbs 16:21 (New Living Translation)
>
> Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> Felix Miata  ***  http://fm.no-ip.com/
>
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Miroslav Suchý]

On 09/10/2013 08:25 AM, Dan Horák wrote:
> > > I did a TC5 minimal install last night, which omitted mc, my most
> > > used cmdline tool. So:
> > >
> > > # yum install mc
> > > ... installing for dependencies:
> > > gpm-libs (which I never ever use)
> > > perl* (29 packages)...
> > >
> > > Seriously? What does mc need perl for?
>
> see /usr/libexec/mc/extfs.d

So unless you try to open deb, rpm package and few other format you do not need perl.
So it is merely nice-to-have. Usually called soft-dependency, which unfortunately our tools still does not know.

Does somebody knows when we can expect soft dependencies in rpm?

[Ian Malone]

On 11 September 2013 08:05, Miroslav Suchý  wrote:
> On 09/10/2013 08:25 AM, Dan Horák wrote:
> > > > I did a TC5 minimal install last night, which omitted mc, my most
> > > > used cmdline tool. So:
> > > >
> > > > # yum install mc
> > > > ... installing for dependencies:
> > > > gpm-libs (which I never ever use)
> > > > perl* (29 packages)...
> > > >
> > > > Seriously? What does mc need perl for?
> >
> > see /usr/libexec/mc/extfs.d
>
> So unless you try to open deb, rpm package and few other format you do not
> need perl.
> So it is merely nice-to-have. Usually called soft-dependency, which
> unfortunately our tools still does not know.
>
> Does somebody knows when we can expect soft dependencies in rpm?

Can someone explain what the consequences of a 'soft dependency' would
actually be and how it would be different from putting those files
into a sub-package? (Which may or may not work depending on whether mc
is able to cope dynamically with that.)
Because when we saw a similar discussion on the user list a while ago
it seemed that people expected it to simply know that they wouldn't
need feature X of package Y and therefore magically leave it out but
still have the application run successfully.

[Matej Cepl]

On 2013-09-11, 09:36 GMT, Ian Malone wrote:
> Can someone explain what the consequences of a 'soft dependency' would
> actually be and how it would be different from putting those files
> into a sub-package? (Which may or may not work depending on whether mc
> is able to cope dynamically with that.)

See http://www.debian.org/doc/debian-policy/ch-relationships.html 
(section 7.2 for definition of Suggests and Recommends). And of course, 
all this matter only if yum, PackageKit, etc. know about these 
suggested/recommended packages and have some way how to deal with them.  
Debian apt* programs have either option to always follow/not-follow 
these soft-dependencies, or they will just select for installation all 
packages on which the selected package(s) Depends and then nicely ask
user whether she wants to install also suggested/recommended packages.

Matěj

[Miroslav Suchý]

On 09/11/2013 01:24 PM, Matěj Cepl wrote:
> Debian apt* programs have either option to always follow/not-follow
> these soft-dependencies, or they will just select for installation all
> packages on which the selected package(s) Depends and then nicely ask
> user whether she wants to install also suggested/recommended packages.

To be precise IIRC:
* Depends are always installed
* Recommends are selected but you can remove from list before installation
* Suggests and Enhances are offered for selections, but not selected by default and user must select it manually

[Bill Nottingham]

Miroslav Suchý ([e-mail]) said:
> On 09/11/2013 01:24 PM, Matěj Cepl wrote:
> > Debian apt* programs have either option to always follow/not-follow
> > these soft-dependencies, or they will just select for installation all
> > packages on which the selected package(s) Depends and then nicely ask
> > user whether she wants to install also suggested/recommended packages.
>
> To be precise IIRC:
> Depends are always installed
> Recommends are selected but you can remove from list before installation
> Suggests and Enhances are offered for selections, but not selected by default and user must select it manually

The problem with soft dependencies has always been the semantics and the
workflow, not the implementation.  Even as you describe here with defined
semantics, that makes assumptions about the workflow, namely that to make
use of them:
- the installers are interactive in ways that most of our frontends aren't
- that we're designing for the case where the person handling software
  installation is interested in this level of platform micromanagement
  (Admittedly, our focus on exposing individual RPMs to the user drives this
  issue in spades, and in fact drives how our entire ecosystem works, or,
  in many cases, doesn't work.)

Bill

[Vít Ondruch]

Dne 11.9.2013 21:54, Bill Nottingham napsal(a):
> The problem with soft dependencies has always been the semantics and 
> the workflow, not the implementation.

So do we have the implementation? I am afraid not, since this "problem" 
is always used as an excuse why not implement it. But discussing 
workflow without implementation makes no sense IMO.

Vít

[Miloslav Trmač]

On Fri, Sep 20, 2013 at 5:12 PM, Vít Ondruch  wrote:
> Dne 11.9.2013 21:54, Bill Nottingham napsal(a):
> > The problem with soft dependencies has always been the semantics and the
> > workflow, not the implementation.
>
> So do we have the implementation? I am afraid not, since this "problem" is
> always used as an excuse why not implement it. But discussing workflow
> without implementation makes no sense IMO.

We can probably implement any semantics once we know what it should
be.  OTOH, we shouldn't start using an implementation of specific
semantics if the semantics is highly risky to be useless; sure, doing
so would allow us to "declare success" that we have soft dependencies,
but it would be a hollow victory.

(IMHO, disk space is cheap enough that just using hard Requires: is
rarely wrong enough to worry about it.)
    Mirek

[Reindl Harald]

Am 20.09.2013 17:18, schrieb Miloslav Trmač:
> (IMHO, disk space is cheap enough that just using hard Requires: is
> rarely wrong enough to worry about it.)

no it is *not*

in cloud infrastructure where you have 100, 500, 1000
instances and need to reserve 50 or 150 MB more for the
base OS because dependencie chains you end easily in
a lot of gigabytes and not only the space, also the
time updates on all the instances takes

additionally there is a security point of view

take a look which software comonents in the last few
months had security-fixes where i even did not condiser
that they could open a security hole willingly

with every pulled and distributed dependency you raise
the amount of code with potential unknown security
relevant bugs

[Bill Nottingham]

Reindl Harald ([e-mail]) said:
> Am 20.09.2013 17:18, schrieb Miloslav Trmač:
> > (IMHO, disk space is cheap enough that just using hard Requires: is
> > rarely wrong enough to worry about it.)
>
> no it is *not*
>
> in cloud infrastructure where you have 100, 500, 1000
> instances and need to reserve 50 or 150 MB more for the
> base OS because dependencie chains you end easily in
> a lot of gigabytes and not only the space, also the
> time updates on all the instances takes
>
> additionally there is a security point of view
>
> take a look which software comonents in the last few
> months had security-fixes where i even did not condiser
> that they could open a security hole willingly
>
> with every pulled and distributed dependency you raise
> the amount of code with potential unknown security
> relevant bugs

Sure, it's a good principle, but you also have to tailor it to the
situations where it's applied.

For example, are people *really* using mc for work inside cloud images?  If
it's a tool that is confined to administator console usage on their
laptop/workstation, you could argue that there are different criteria for
what is considered an 'excessive' dependency.

Bill

[Reindl Harald]

Am 20.09.2013 20:26, schrieb Bill Nottingham:
> Reindl Harald ([e-mail]) said:
> > Am 20.09.2013 17:18, schrieb Miloslav Trmač:
> > > (IMHO, disk space is cheap enough that just using hard Requires: is
> > > rarely wrong enough to worry about it.)
> >
> > no it is *not*
> >
> > in cloud infrastructure where you have 100, 500, 1000
> > instances and need to reserve 50 or 150 MB more for the
> > base OS because dependencie chains you end easily in
> > a lot of gigabytes and not only the space, also the
> > time updates on all the instances takes
> >
> > additionally there is a security point of view
> >
> > take a look which software comonents in the last few
> > months had security-fixes where i even did not condiser
> > that they could open a security hole willingly
> >
> > with every pulled and distributed dependency you raise
> > the amount of code with potential unknown security
> > relevant bugs
>
> Sure, it's a good principle, but you also have to tailor it to the
> situations where it's applied.

in doubt keep the footpürint as small as possible

i reduced the used space in rootfs on our virtual servers running
Fedora within the last year about 600 MB by remove "nice to have"
packages with expensive cross dependencies - with the expierience
from now i would have reserved 30 GB less on the SAN storage and
in such environments diskspace is *not cheap* - the opposite is
the truth - fast SAS discs are *very* expensive and you need at
least 6 to 8 in a spindle for performance/Failover

oh - and in such envorinments you have typically *versioned backups*
of the complete images including the root FS, multiply the space
and if it comes to offsite-backups condsider the time and bandwith

as you can see things are not that simple like "a few MB" if someone
is looking at the big picture and not only his personal pieces
> For example, are people *really* using mc for work inside cloud images?

since it is a console app - why not?
> If it's a tool that is confined to administator console usage on their
> laptop/workstation, you could argue that there are different criteria for
> what is considered an 'excessive' dependency

who is using "mc" on a full featured desktop?
typically it is used where you do not have a fat graphical filemanager

well, some people would now say "i do"
the same i can say for sure to some other pakcages on a cloud server where
they would disagree and because everybody has different needs keep the
dependency chain as small as possible is always a good idea for a lot
of reasons and save ressources is generally a good idea even if most of
the young devlelopers never learned how to develop tiny, bugfree and
stable software - the results are well known

[Jakub Jelinek]

On Fri, Sep 20, 2013 at 08:37:50PM +0200, Reindl Harald wrote:
> well, some people would now say "i do"
> the same i can say for sure to some other pakcages on a cloud server where
> they would disagree and because everybody has different needs keep the
> dependency chain as small as possible is always a good idea for a lot
> of reasons and save ressources is generally a good idea even if most of
> the young devlelopers never learned how to develop tiny, bugfree and
> stable software - the results are well known

But for the mc dependency on perl, I'd say it is very reasonable one to have, because
otherwise none of the extfs will really work, that is something used pretty
frequently in mc.  Of course unless you are prepared to rewrite all the
scripts into awk, plain sh or something that will require smaller footprint.

Jakub

[Reindl Harald]

Am 20.09.2013 21:13, schrieb Jakub Jelinek:
> On Fri, Sep 20, 2013 at 08:37:50PM +0200, Reindl Harald wrote:
> > well, some people would now say "i do"
> > the same i can say for sure to some other pakcages on a cloud server where
> > they would disagree and because everybody has different needs keep the
> > dependency chain as small as possible is always a good idea for a lot
> > of reasons and save ressources is generally a good idea even if most of
> > the young devlelopers never learned how to develop tiny, bugfree and
> > stable software - the results are well known
>
> But for the mc dependency on perl, I'd say it is very reasonable one to have, because
> otherwise none of the extfs will really work, that is something used pretty
> frequently in mc.  Of course unless you are prepared to rewrite all the
> scripts into awk, plain sh or something that will require smaller footprint

and that is why the thread subject is "does mc really require perl*?" which was
clearly a question - and could have been  aswered exactly as you did now

in the first front i answered to the mindless "disk space is cheap these days"
because this sloppy attitude leads to a lot of wrong decisions all over the
time - not all what seems to be cheap is it in reality and even if - not all
which is cheap is smart at the end of the day

[Martin Sourada]

On Fri, 20 Sep 2013 20:37:50 +0200 
Reindl Harald wrote:
> who is using "mc" on a full featured desktop?
> typically it is used where you do not have a fat graphical filemanager

Point me to such graphical filemanager. I fail to see even a decent gui
alternative to mc under linux. MC *is* typically used on a full featured
desktop because it's the most effective tool in linux world to actually
manage files, not just browse through them and open. All the gui "file
managers" I've ever tried under linux either have terrible gui or are
file *browsers* rather than file *managers*. People on linux use mc for the
same reason people on windows install either total commander or
servant salamander.

Sorry for the OT, but I couldn't hold back on this remark.

Thanks,
Martin

mc alternative: Double Commander

[Vít Ondruch]

Dne 22.9.2013 10:32, Martin Sourada napsal(a):
> Point me to such graphical filemanager. I fail to see even a decent 
> gui alternative to mc under linux.

You can try Double Commander if you like.

http://doublecmd.sourceforge.net/
http://vondruch.fedorapeople.org/doublecmd/doublecmd.repo

Vít

mc alternative: Double Commander

[Christopher Meng]

Side note:

I've also sent review request to the BZ.

If someone can give me a better solution of gtk/qt widgetset, which
means keeping these 2 in 1 package, welcome.

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

mc alternative: Double Commander

[Hans de Goede]

Hi,

On 09/23/2013 11:44 AM, Christopher Meng wrote:
> Side note:
>
> I've also sent review request to the BZ.
>
> If someone can give me a better solution of gtk/qt widgetset, which
> means keeping these 2 in 1 package, welcome.

Yes, do the build twice, including running %configure twice
with a make distclean in between.

IE something like

%configure --with-qt4
make
mv doublecmd doublecmd-qt4
make distclean
%configure --with-gtk2
make

And then in %install manually install the binary you saved from
getting nuked by make distclean by moving it out of the way.

This way you can have one srpm, named simply doublecmd, with
-qt4 and -gtk2 sub-packages. You can then use the main
package to store common files and make both require it,
or simple don't have a "%files" only a "%files qt4" and
"%files gtk2" and then rpmbuild won't create a main
binary package, only the 2 subpackages (while still
creating a single src rpm named after the main package).

This seems like the best way to deal with this to me (and is
how things like this are done in numerous other packages).

Please try this, if you get stuck, send me a link to
an srpm with your attempts and I'll try to fix it, I might
even review this :)

Regards,

Hans

mc alternative: Double Commander

[Martin Sourada]

On Mon, 23 Sep 2013 10:59:55 +0200 
Vít Ondruch wrote:
> Dne 22.9.2013 10:32, Martin Sourada napsal(a):
> > Point me to such graphical filemanager. I fail to see even a decent 
> > gui alternative to mc under linux.
>
> You can try Double Commander if you like.

I'd expect much less wasted space in a good mc alternative, but thanks for
the pointer, I'll give it a spin when I have some spare time :)

Martin

[Petr Pisar]

On 2013-09-11, Bill Nottingham  wrote:
> The problem with soft dependencies has always been the semantics and the
> workflow, not the implementation.  Even as you describe here with defined
> semantics, that makes assumptions about the workflow, namely that to make
> use of them:
> the installers are interactive in ways that most of our frontends aren't

False. You can decide soft dependencies on preconfigured base. See
Gentoo portage tool. It's hell of soft dependencies and it's not
interactive.
> that we're designing for the case where the person handling software
> installation is interested in this level of platform micromanagement

Again you can leave the decision to a default, if you worry a user gets
confused.

-- Petr

[Marcin Juszkiewicz]

W dniu 11.09.2013 09:05, Miroslav Suchý pisze:
> So it is merely nice-to-have. Usually called soft-dependency, which
> unfortunately our tools still does not know.
>
> Does somebody knows when we can expect soft dependencies in rpm?

IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 
years ago. We used such ones in OpenEmbedded to get rpm packages more in 
par with ipk/deb ones.

[Miroslav Suchý]

On 09/11/2013 02:18 PM, Marcin Juszkiewicz wrote:
> IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 years ago.

Suse as well.

[Michael Cronenworth]

Miroslav Suchý wrote:
> On 09/11/2013 02:18 PM, Marcin Juszkiewicz wrote:
> > IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 years
> > ago.
>
> Suse as well.

Is there a bug opened for this enhancement?

I know it has been talked about for years, but nothing has come out of mailing 
list discussions. A quick BZ search turned up nothing.

[Miroslav Suchý]

On 09/11/2013 04:39 PM, Michael Cronenworth wrote:
> Is there a bug opened for this enhancement?
>
> I know it has been talked about for years, but nothing has come out of mailing list discussions. A quick BZ search
> turned up nothing.

You are correct! To my surprise.
But this can be easily fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1006954
Lets watch this :)

[Chris Adams]

Once upon a time, Miroslav Suchý  said:
> On 09/11/2013 04:39 PM, Michael Cronenworth wrote:
> > Is there a bug opened for this enhancement?
> >
> > I know it has been talked about for years, but nothing has come out of mailing list discussions. A quick BZ search
> > turned up nothing.
>
> You are correct! To my surprise.
> But this can be easily fixed:
> https://bugzilla.redhat.com/show_bug.cgi?id=1006954
> Lets watch this :)

The problem is that many (most?) programs won't handle this well.  For
example, how does mc handle having its perl scripts installed but
non-functional?  If it is a graceful failure (an error message that
tells you what to do), then maybe a soft dependency would be okay.  If
you just get a meaningless "it failed" message (or worse, mc breaks,
crashes, etc.), then a soft dependency would not be a good thing.

In addition, the package managers need some way later to easily install
uninstalled soft dependencies, so when mc doesn't work, someone can just
say "add what's needed", rather than end-users having to hunt down what
is really required to make the external scripts work.

Anything that results in more bugs being reported in Bugzilla will not
be used by packagers.  If soft dependencies existed, and mc used them,
the mc packager would most likely stop using them if there were a bunch
of "I get perl error" bug reports.

There's a lot of work needed to make soft dependencies work "right", and
it isn't all that clear that they'd really be useful in a wide variety
of cases.

[Michael Schwendt]

On Wed, 11 Sep 2013 10:11:12 -0500, Chris Adams wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1006954
> The problem is that many (most?) programs won't handle this well.  For
> example, how does mc handle having its perl scripts installed but
> non-functional?

The "missing extfs.d script" case is trivial. MC simply doesn't offer
a virtual filesystem for the file type.

If the script interpreter is missing, it prints a detailed "bad
interpreter" error.
> In addition, the package managers need some way later to easily install
> uninstalled soft dependencies, so when mc doesn't work, someone can just
> say "add what's needed", rather than end-users having to hunt down what
> is really required to make the external scripts work.

Perhaps similar to a reinstall of "mc", asking the user about what
optional deps to add. And hopefully it's not subpackages that contain
optional deps with the user running into trouble finding the package
which to reinstall/enhance.

[Richard W.M. Jones]

On Tue, Sep 10, 2013 at 08:25:59AM +0200, Dan Horák wrote:
> On Mon, 09 Sep 2013 20:27:09 -0400
> Felix Miata  wrote:
> > I did a TC5 minimal install last night, which omitted mc, my most
> > used cmdline tool. So:
> >
> > # yum install mc
> > ... installing for dependencies:
> > gpm-libs (which I never ever use)
> > perl* (29 packages)...
> >
> > Seriously? What does mc need perl for?
>
> see /usr/libexec/mc/extfs.d

mc is also missing a dependency on dpkg!

Rich.

[Matej Cepl]

On 2013-09-11, 15:56 GMT, Richard W.M. Jones wrote:
> mc is also missing a dependency on dpkg!

Not really. If some esteemed Perl hacker here would be willing to spent 
some time on /usr/libexec/mc/extfs.d/dpkg+ I think it could be possible 
to get it into shape. Deb archives are nothing than else than ar(1) 
archives in disguise (i.e., it is possible to do ar x file.deb to get to 
it).

Best,

Matěj