Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 110880 - x11-apps/xinit has unecessary dependencies
Summary: x11-apps/xinit has unecessary dependencies
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Highest normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
: 137303 149011 424205 (view as bug list)
Depends on:
Blocks: 112004
  Show dependency tree
 
Reported: 2005-10-30 04:29 UTC by robustah
Modified: 2012-08-09 22:49 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description robustah 2005-10-30 04:29:28 UTC
x11-wm/twm
x11-apps/xclock
x11-terms/xterm

Remove them please.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Joshua Baergen (RETIRED) gentoo-dev 2005-10-30 09:02:39 UTC
Have you looked at the /etc/X11/xinit/xinitrc provided?

# Failsafe
else
        # start some nice programs
        twm &
        xclock -geometry 50x50-1+1 &
        xterm -geometry 80x50+494+51 &
        xterm -geometry 80x20+494-0 &
        exec xterm -geometry 80x66+0+0 -name login
fi

Those deps can't be dropped unless the failsafe state changes.  I'm certainly
open for suggestions for a failsafe state that doesn't require these apps.  I
see no reason why we can't drop xclock, for example.

Donnie, Robert, ideas/rationale?
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2005-10-30 11:00:44 UTC
Rationale being that this has been the traditional failsafe state for ages, so
people expect to see it.
Comment 3 robustah 2005-10-30 11:10:37 UTC
No I haven't, but I did now. So just because the apps are used in failsafemode
that means that everyone needs to install them? I have never used a failsafemode
when it comes to X and I can't see why I would want to. I just want to keep my
modular X installation clean and not bloat it with several things that I don't
need. Hopefully this situation will be taken care of my someone with better
insight on the matter than me, and also that changes are made that pleases both
sides. Failsafers and Nosafers alike :)
Comment 4 Steev Klimaszewski (RETIRED) gentoo-dev 2005-10-30 19:26:13 UTC
i can understand the reasoning behind having them, it would still be nice to
have the ability to not pull them in.
Comment 5 Joshua Baergen (RETIRED) gentoo-dev 2005-10-30 22:03:25 UTC
However, we cannot install a script that relies on things that are optional.  
The script itself would have to drop the failsafe state when the failsafe apps 
were not installed.

Maybe this would fall under a "minimal" USE-flag?
Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2005-10-30 23:11:34 UTC
(In reply to comment #5)
> However, we cannot install a script that relies on things that are optional.  
> The script itself would have to drop the failsafe state when the failsafe apps 
> were not installed.
> 
> Maybe this would fall under a "minimal" USE-flag?

I don't think it's worth it, unless there's some sort of actual benefit besides
"the cruft," because even added together, they install less than 1MB worth of files.
Comment 7 Petteri Räty (RETIRED) gentoo-dev 2005-10-31 00:25:44 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > However, we cannot install a script that relies on things that are optional.  
> > The script itself would have to drop the failsafe state when the failsafe apps 
> > were not installed.
> > 
> > Maybe this would fall under a "minimal" USE-flag?

That would be ok by me.

> 
> I don't think it's worth it, unless there's some sort of actual benefit besides
> "the cruft," because even added together, they install less than 1MB worth of
files.

It is not that much about the amount of space. It is more about the feeling that
you don't have anything you don't need installed. And some people like to look
through their list of updates to see what has changed and so on, so when there
are less packages it takes less time.
Comment 8 Stefan Schweizer (RETIRED) gentoo-dev 2005-11-01 07:50:14 UTC
Please remove the depends or make them conditional.
That is the point of modular X .. not having to insstall apps you do not need.

I would prefer some sort of "fallback"-USE-flag so that the depends are default
off .. with "minimal" they would be default on and users would have to add xinit
to package.use.
Comment 9 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-01 09:33:19 UTC
It might be worth comparing our xinitrc with upstream's to see whether there are
differences in the runtime dependencies.
Comment 10 Stefan Schweizer (RETIRED) gentoo-dev 2005-11-03 05:23:15 UTC
Can we please have something like that?
What is the problem with it?

# diff -u xinitrc.orig xinitrc
--- xinitrc.orig        2005-11-03 14:19:08.000000000 +0100
+++ xinitrc     2005-11-03 14:21:40.000000000 +0100
@@ -34,10 +34,5 @@
        exec "`/etc/X11/chooser.sh`"
 # Failsafe
 else
-       # start some nice programs
-       twm &
-       xclock -geometry 50x50-1+1 &
-       xterm -geometry 80x50+494+51 &
-       xterm -geometry 80x20+494-0 &
-       exec xterm -geometry 80x66+0+0 -name login
+       echo "No session found in $HOME/.xinitrc and /etc/X11/chooser.sh" >&2
 fi
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-03 10:31:24 UTC
What is wrong with it is that there is no fallback. It's this thing about
usability where having working X is important, even if it's using twm. And it's
a lot more important to have working X than to not install 1MB worth of apps.
Comment 12 Petteri Räty (RETIRED) gentoo-dev 2005-11-03 10:41:11 UTC
(In reply to comment #11)
> What is wrong with it is that there is no fallback. It's this thing about
> usability where having working X is important, even if it's using twm. And it's
> a lot more important to have working X than to not install 1MB worth of apps.

Well then we could probably disable the python use flag. It just installs
language bindings that are probably useful in some cases and don't take so much
space. What is wrong with having a for example a xsession or something like that
use flag pulling these in? After something is implemented for bug 61732 it can
be on by default.
Comment 13 Joshua Baergen (RETIRED) gentoo-dev 2005-11-13 11:55:42 UTC
(In reply to comment #9)
> It might be worth comparing our xinitrc with upstream's to see whether there 
are
> differences in the runtime dependencies.
Nope, our fallback is exactly the same.
Comment 14 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-13 14:27:38 UTC
OK, then this is not going to change in Gentoo without changing upstream. For
that reason, I'm marking it upstream.

Feel free to file an upstream bug, although I don't expect they'll be willing to
change it either, because a sane fallback just makes sense.
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2006-06-19 14:58:40 UTC
*** Bug 137303 has been marked as a duplicate of this bug. ***
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2006-09-24 23:02:47 UTC
*** Bug 149011 has been marked as a duplicate of this bug. ***
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2007-02-28 11:04:47 UTC
*** Bug 168698 has been marked as a duplicate of this bug. ***
Comment 18 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-03-21 01:47:26 UTC
*** Bug 263192 has been marked as a duplicate of this bug. ***
Comment 19 Jeroen Roovers (RETIRED) gentoo-dev 2012-06-30 15:29:11 UTC
*** Bug 424205 has been marked as a duplicate of this bug. ***
Comment 20 Jeroen Roovers (RETIRED) gentoo-dev 2012-07-02 03:31:28 UTC
*** Bug 424205 has been marked as a duplicate of this bug. ***
Comment 21 Jeroen Roovers (RETIRED) gentoo-dev 2012-07-02 10:59:17 UTC
*** Bug 424205 has been marked as a duplicate of this bug. ***
Comment 22 Dave Kemper 2012-07-02 20:35:01 UTC
The last human response to this bug, in 2005, was comment #14, which concluded, based on discussion in the previous comments:

> OK, then this is not going to change in Gentoo without changing upstream.

Sometime between then and now, the package dependencies /were/ changed in Gentoo without the xinitrc script changing upstream: the broken configuration that comment 5 and comment 11 advise against is now in the x11-apps/xinit-1.3.1-r1 package.  I do not know when or why xinit's dependencies were changed.

I don't have a strong opinion on whether this should be solved by changing the fallback configuration, or restoring the x11-apps/xinit dependencies, or doing something else entirely, but xinit should not have a default configuration which simply fails to work, as it does now.
Comment 23 Chí-Thanh Christopher Nguyễn gentoo-dev 2012-07-02 20:53:19 UTC
What the user has to do to get a working startx is properly documented in the x11 documentation: http://www.gentoo.org/doc/en/xorg-config.xml#doc_chap3_sect3

xinit works perfectly fine without twm and xterm. If the user doesn't want them, there is no reason to force an install.
Comment 24 Dave Kemper 2012-07-11 23:59:11 UTC
(In reply to comment #23)
> xinit works perfectly fine without twm and xterm. If the user doesn't want
> them, there is no reason to force an install.

A quite valid reason was given in comment #11.  It's fine if you don't agree with this reason, but it is, in fact, a reason.  So saying "there is no reason" is disingenuous.

If Donnie Berkholz's reason is deemed no longer important, then a patch like the one proposed in comment #10 would be very simple to make, and would prevent a broken default xinitrc script.

Because it sure seems to me that there is no reason to ship xinit with a default configuration that simply does not work.
Comment 25 Chí-Thanh Christopher Nguyễn gentoo-dev 2012-07-12 00:21:33 UTC
If it is properly documented how to make it work (and I think it is, if you disagree please point out deficiencies), then "doesn't work" type problems with the default configuration are secondary IMO. Worst thing that happens is that startx fails, complaining about missing twm/xterm.
Comment 26 Dave Kemper 2012-08-09 22:49:53 UTC
(In reply to comment #25)
> If it is properly documented how to make it work (and I think it is, if you
> disagree please point out deficiencies),

It's not documented in the package at all.  The document you pointed to is an external page.  If this were still 2005, when there was no reasonable way to get an X installation running without a lot of coaxing and hand-holding, requiring an outside install guide would be a reasonable requirement.  Today's X can nearly be emerged and run without needing an install guide.  In general, over time it's only moving closer to this ideal; including a broken default configuration moves it further away.

> then "doesn't work" type problems
> with the default configuration are secondary IMO.

What has changed since 2005 about the principles of usability to render Donnie's comment #11 obsolete?

> Worst thing that happens
> is that startx fails, complaining about missing twm/xterm.

Since the fallback configuration starts twm (and xclock) in the background, no error message at all is generated.  When the foregrounded xterm tries to start, it gives the error "xterm: xterm: cannot execute binary file", a misleading error message, as it implies there is an xterm binary on the system that for some unspecified reason cannot be executed.

At a bare minimum, if the packages necessary for the fallback configuration aren't installed, the fallback portion of xinitrc should detect this and generate a meaningful error message, preferably something that gives specific steps to solve the problem.  This would be a pretty simple change to xinitrc, and would help preserve usability without forcing installation of extra packages.