[Solved] tce.installed/Xlibs functionality

[jazzbiker]

Hi Core people!

I have the questions about the purpose of the last 2 lines in /usr/local/tce.installed/Xlibs script:

Code: [Select]

s_u_d_o chown -R root.staff /usr/local/tce.installed 2>/dev/null
s_u_d_o chmod -R 775 /usr/local/tce.installed 2>/dev/null
I am asking not because of any problems, just to understand better. The question raised after I took the look into the /usr/local/tce.installed directory and found that zero-sized files, simply marking the extensions' presence have execution permissions and have varying ownerships (root:staff and tc:staff). Some experiments allowed me to notice that such diversity appears after Xlibs.tcz installation.

Was that made to ensure that all tce.installed/* scripts are executable? Is it the historical artefact? Some kind of protection against packagers' mistakes?
Just curious, no trouble.

As an experiment I've commented these 2 lines and everything seems to work. Is this experiment dangerous?

Best regards!

[NewUser]

The first line changes ownership of tce.installed to root and staff. Errors that might have been written to screen are sent to /dev/nul. Nowhere.

Line 2 changes the permissions to tce.installed. Owner (root) and group (staff) can read and write to tce.installed. Any user can only read, and execute tce.installed.

[curaga]

Probably just a check for packaging mistakes, yeah.

[jazzbiker]

The first line changes ownership of tce.installed to root and staff. Errors that might have been written to screen are sent to /dev/nul. Nowhere.

Line 2 changes the permissions to tce.installed. Owner (root) and group (staff) can read and write to tce.installed. Any user can only read, and execute tce.installed.

Thanks for the explanation! Agreed with additional note that both operations are applied recursively (-R) with all the consequences following.

[jazzbiker]

Probably just a check for packaging mistakes, yeah.

So, nothing special, I see. I guess these two lines were born in the pre-submitqc era Submitqc is very handy and helpful. I guess now all the extensions are submitqc-ed and looks ideal from the point of view of tce.installed/* ownership and permissions.
By the way, the two above mentioned commands are applied in the recursive manner and thus cause violation of the recommended in the Corebook ownership and permissions for the scripts:

"The install scripts should be owned by tc:staff and have executable permissions. The tce.installed directory should be owned by root:staff and have 775 permissions "

page 77.

After these commands applied recursively script files have root:staff owner.

Thanks for the reply, I was afraid I can break something necessary.

I want to describe one X-related surprise I faced and it made me stuck for a while.
Booting in text mode, then "tce-load -i Xfbdev" and "startx". Compiling something X-based needs "tce-load -i xorg-server-dev". Implicitly it causes my "/etc/susconfig/Xserver" to contain "Xorg". Then for some reason leaving X (which is Xfbdev at that moment). Then after making the console jobs starting X again ... and ... surprise-surprise! I'm in Xorg. And if graphics-* is absent it is not so fast to understand what's going on
Of course such a situation is rarity, but this makes it even less pleasant, because I need to realize once again what happened I want to say that if

Code: [Select]

e_c_h_o Xorg > ...
will be conditional like

Code: [Select]

[ -e ... ] || e_c_h_o Xorg > ...
then Xfbdev will not be displaced. The opposite situation (initial Xorg and then Xfbdev) seems to much less probable. Please consider this description as a kind of short story, not a request. Only occasional Xfbdev user may be caught with this trap.

Regards!

[curaga]

Well, xorg-server-dev does pull down Xorg, since it's also used to build Xorg drivers (against the server). You can compile X apps with just the various lib -dev extensions, but there may not be one easy file that grabs them all as deps.

Xfbdev installed to Xorg: that's the default scenario on CorePure, isn't it? Ships with Xfbdev, and users may want to install Xorg.

[jazzbiker]

Well, xorg-server-dev does pull down Xorg, since it's also used to build Xorg drivers (against the server). You can compile X apps with just the various lib -dev extensions, but there may not be one easy file that grabs them all as deps.

Yes, and this is not the problem. The problem (for me personally, no more) is to recall that sometimes (maybe twice a year) I need to

Code: [Select]

_echo_ Xfbdev | _sudo_ _tee_ /etc/sysconfig/Xserver
because if graphics-KERNEL is not installed on slow boxes Xorg turns into Xsleepy-turtle

Xfbdev installed to Xorg: that's the default scenario on CorePure, isn't it? Ships with Xfbdev, and users may want to install Xorg.

And this is definitely the most newcomers-friendly way.

So I'll try to summarize, that if empty executables in the tce.installed directory are bothering me I can fearlessly turn off the last two lines in the Xlibs script and this will not cause any troubles, assuming that Xlibs deps are packed correctly, and they really are in fact.

@curaga, thanks for refinement!

@Rich, my question is answered, can You please mark the thread as the solved one?

[Rich]

Hi jazzbiker
Done.