Le 27/12/2013 17:03, Bruce Dubbs a écrit :
> Fernando de Oliveira wrote:
>> Em 27-12-2013 09:26, Pierre Labastie escreveu:
>>> Hi,
>>>
>>> As you may have seen, I have added xorg-env as a dependency of xbitmaps. But
>>> since xbitmaps is required by Xorg applications, which also requires 
>>> mesalib,
>>> which requires xcb-proto and the like, it may be not necessary. However,
>>> theoretically, a user following the dependencies for X server backward may 
>>> end
>>> up building xbitmaps as the first package in the X chapter (I agree that the
>>> probability is small).
>>
>> I would keep it as you modified (actually, I missed that, when studying
>> the problem).
>>
>>> Furthermore xscreensaver requires only Xorg
>>> applications (well, that is king of weird to me, but Armin has arguments 
>>> about
>>> the server running remotely). In this case, the probability is slightly 
>>> higher.
>>
>> This should be fixed to include the whole xorg as required runtime
>> dependency.
>>
>>>
>>> There is also something which bothers me: when a dependency refers to X 
>>> Window
>>> system, where should the user begin? The id "x-window-system" refers to the
>>> beginning of the chapter, but nowhere it is said what should be built to 
>>> get a
>>> working X installation (actually, the xcb-util-xxx packages are not needed 
>>> for
>>> a basic installation, and neither are xclock, twm, xterm nor xinit, although
>>> the last four are useful to do the first tests of Xorg).
>>
>> I had the same problem, when fixing fop, earlier today, and did what
>> thought was best. But a better definition of a working xorg for runtime
>> dependencies would be good, perhaps it is just xorg-drivers or xinit?
> 
> I think we may be getting too carried away with this.  For the vast 
> majority of users, they will build Xorg in sequence from Introduction to 
> Testing.  Handling other situations seems to be overkill.  Sure, twm may 
> not be needed, but it really doesn't hurt.  When the package needs Xorg, 
> just saying Xorg should be enough.  Which piece(s) is/are not that 
> important.
> 
I agree that saying "Xorg" is enough, except that quite a few packages in the
book have now deps to part of it (Xorg apps, or Xorg libs or Xorg proto for
the most used), and the point of the discussions these days was that users
should be able to find dependencies backward from where they are pointed to. I
too think that it is overkill, but since what has been done broke ablfs
(jhalfs-blfs if you prefer), I thought I could ask what directions it was
going to.
>>> BTW, shouldn't twm be added to the deps of xinit, at the same level as xterm
>>> and xclock? Right now xterm and xclock are "required (runtime only)", and 
>>> twm
>>> is not mentioned. Strictly speaking, none of the three are required, even at
>>> runtime: you could build another terminal (say rxvt), forget about xclock,
>>> build another WM, and start them in ~/.xinitrc. Of course, If you keep the
>>> defaults, xclock, xterm and twm are started by xinit? So I suggest to put 
>>> them
>>> as "recommended (used by default at runtime)".
>>
>> Perhaps.
>>
> 
> I don't think so.  The book has had the same general layout since about 
> 2004 and this is really the first time it's come up.  Advanced users 
> should know enough to be able to make changes on their own.  If not, 
> they should just follow the book.
Well, the book layout _has_ changed: twm, xclock, xterm and xinit were all
inside Xorg apps until June 11th, 2012, when "dj" moved them out to the end of
the chapter. My point is that currently, only xterm ans xclock are mentioned
as xinit deps (required, runtime only), while twm, which should be at the same
level as the others, is not mentioned. I agree that the second point (change
to just recommended) is cosmetic. We could as well remove all deps, and let
the user figure for himself, or do whatever fits best, but for all three
packages or none. I do not like being halfway...

Pierre
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to