[blfs-dev] Dependencies in X chapter

Bruce Dubbs bruce.dubbs at gmail.com
Fri Dec 27 09:28:24 PST 2013


Fernando de Oliveira wrote:
> Em 27-12-2013 13:03, Bruce Dubbs escreveu:
>> 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.
>>
>
> LOL. OK, let us not be carried away. Actually, the main problem leading
> here was not user errors, but devs complaints.
>
>>>> 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.
>
> I really agree that modifications of the book's layout should be
> completely avoided.
>
> I promised  Pierre to not change his modifications in subversion, but
> every time I look at that page, I see that it is inconsistent with the
> rest of the book.
>
> To Pierre: please, I would like you to agree with me and then I would
> modify back subversion format (not dependencies nor technical parts).

Yes, although it looks nice, it needs to be consistent with the rest of 
the book.

   -- Bruce




More information about the blfs-dev mailing list