Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 90789 - x11-prefix.eclass for the /usr/X11R6 -> /usr move in ebuilds
Summary: x11-prefix.eclass for the /usr/X11R6 -> /usr move in ebuilds
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo X packagers
URL: http://thread.gmane.org/gmane.linux.g...
Whiteboard:
Keywords:
Depends on:
Blocks: 90794 90796 90797 90799 90800 90801 90802 90803 91070 91071
  Show dependency tree
 
Reported: 2005-04-28 16:53 UTC by TGL
Modified: 2006-03-31 19:05 UTC (History)
3 users (show)

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


Attachments
x11-prefix.eclass (x11-prefix.eclass,2.13 KB, text/plain)
2005-04-28 16:54 UTC, TGL
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TGL 2005-04-28 16:53:42 UTC
Following the -dev discussion at the above URL, i've started converting some ebuilds to using /usr as the X11 prefix. Basically, the goal is that in a far future we can live without the /usr/X11R6 symlink around.

The tiny eclass i will attach here was written for that task. It provides:
 - a $X11_PREFIX variable which can be either /usr/X11R6 or /usr depending of your existing X11 setup. This variable is set by the pkg_setup() function.
 - a boolean function, new_x11_prefix(), which returns 0 if $X11_PREFIX=/usr
 - a fix_Imake_Makefile() function which applies various sed fixes to Makefiles produced by "xmkmf" in packages which use Imake.

So far, i've adapted the following ebuilds to this eclass:
app-text/gv-3.5.8-r4
dev-games/clanlib-0.7.8-r1
media-gfx/xfig-3.2.4-r2
net-print/xprint-009.1
x11-libs/neXtaw-0.15.1
x11-libs/qt-3.3.4-r3
x11-misc/numlockx-1.0
x11-misc/synaptics-0.14.1
x11-misc/ttmkfdir-3.0.9-r2

With that plus many other recompilations, my system seems to be free of references to /usr/X11R6 in:
 - package CONTENTS (but xorg-x11 sure)
 - .la libtool files
 - binaries and .so libs headers

Next steps will be tracking /usr/X11R6 references in text files (scripts, config files, etc.) and in the portage tree for ebuilds i don't use. I will continue that work, but if someone convince me that it's really to much a waste of time :)

I will report ebuilds changes in separate bugs, but this one will serve as a tracker.

Random notes:

 * there should be no backward compatibility issue: ebuilds i've modified should not have changed their behavior on system still using /usr/X11R6 as a real directory, and the /usr/X11R6 symlink does the rest.

 * binary packages built on a /usr system and then installed on an old /usr/X11R6 system may have troubles though (dynamic linking). I will probably add a pkg_preinst() check in the eclass to warn users in that case, or something like that. 

 * getting rid of all '-L/usr/X11R6' in .la files may goes through _a lot_ of recompilations, because this things are really contagious. I was surprised that, on my system, only two libs packages (qt and nextaw) were actually still introducing some.
Comment 1 TGL 2005-04-28 16:54:21 UTC
Created attachment 57521 [details]
x11-prefix.eclass
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2005-05-01 20:52:41 UTC
	if [ -d "/usr/X11R6" -a ! -L "/usr/X11R6" ] \
	|| [ -d "${ROOT}usr/X11R6" -a ! -L "${ROOT}usr/X11R6" ] ; then

That's broken. It should _always_ use ROOT, and just checking that it's not a symlink is enough. It won't be a file, so the options are symlink or dir. There are probably no need for quotes here either, since we're checking files instead of strings.

Could you fix up the continuations to second lines so they always tab in? It's a bit inconsistent now. Also change function names so they're all underscores and no hyphens.

This is crying out to be an if/then:
	[ ! -f "${my_file}" ] \
		&& eerror "${my_file}: file not found" \
		&& return 1

fix_Imake_Makefile() should only fix X11-related stuff instead of trying to do some full FHS compatibility stuff. Might want to set up return codes for it too. Doubt you want the last sed to determine success of the whole function, particularly since it's such non-crucial stuff.

In general, it looks pretty good though.
Comment 3 TGL 2005-05-02 00:40:12 UTC
> That's broken. It should _always_ use ROOT, and just checking that it's not a symlink is enough.

Testing both ROOT and / seems safer to me for the case there is a DEPEND but no RDEPEND and X11 is installed only on the / system. Maybe it's a bit a theoritical case, but i think i've seen that already in some some fonts ebuilds (with just a DEPEND, for the mkfont* tools), also i've not really checked. Also, in some ebuilds, there are some explicit references to the / X11 instance (for instance a [ -x /usr/X11R6/bin/xmkmf ] test in the groff ebuild), and i don't wan't to break that in case the / instance use the old prefix whereas the ROOT one uses the new one. So no, really, I think it's safer to:
 - test both X11 instances (if they exist)
 - use /usr/X11R6 as soon as one of the instances is installed there

As for using both -d and -L tests, the point is that {/,$ROOT}usr/X11R6 are not only real dirs or symlinks, but they may also not exist (one of them at least). My "[ -d ... ] && [ ! -L ... ]" tests stand for "path exists and is a real directory", and i see no easier way to test that:
 - "[ -L ... ]" tests stand for "path exists and is a symlink", which is not the negation of the above (using only some -L tests would be wrong for instance if there is a /usr/X11R6 symlink but no X11 installed in ${ROOT}, in which case it's safe to use /usr as the prefix)
 - "[ -d ... ]" tests stand for "path exist and is either a real dir or a symlink to a real dir" (damn bash tests which follow symlinks...), so they don't help much here.


> There are probably no need for quotes here either

I think they are needed for using $ROOT, because it's a user-supplied variable which may contain spaces. Now, that's true that it would be silly to do that and would break with too many ebuilds anyway, but still, in theory, i think that's how it should be done everywhere.  And for the quotes around /usr/X11R6, yep, this ones are absolutly useless - i guess i put them there for consistency of the syntax highlighting beetween this two lines :)
But yeah, i really don't care much, i can remove them.


> Could you fix up the continuations to second lines so they always tab in? It's a bit inconsistent now. 

Well, that's consistent, although you may not like that style. I'm used to not indent lines continuations in "if" conditions, to not visualy mix them with the "then" block. But yeah, i really don't mind, i can change that.


> Also change function names so they're all underscores and no hyphens.

They are all using underscores already, but "x11-prefix_pkg_setup" because in that one "x11-prefix" is the name of the eclass, as expected by EXPORT_FUNCTIONS (and looking in the eclass/ dir, it seems to be the standard to use hyphens there and not underscores).

> This is crying out to be an if/then:
>	[ ! -f "${my_file}" ] \
>		&& eerror "${my_file}: file not found" \
>		&& return 1

Ok, will do.


> fix_Imake_Makefile() should only fix X11-related stuff instead of trying to do
> some full FHS compatibility stuff. 

Only the "s:/usr/local:/usr:" is not directly related to X11, but i thought it was convenient to have it there since that substitution was needed by several ebuilds.  Is that really a problem?  But others stuffs are all directly related to X11, even the "s:/usr/man:/usr/share/man:" (because it actually follows a /usr/X11R6/man->/usr/man substitution done by the generic "s:/usr/X11R6:${X11_PREFIX}:" command)

Oh, btw, could you change ProjectRoot to be /usr instead of /usr/X11R6 in the site.def in your next xorg releases? I think that's where the remaining /usr/X11R6 occurences in xmkmf-generated Makefiles come from (in case that's not already done sure, i've not tried your hard-masked releases).  And a s:/usr/X11R6:/usr: on xfs and xdm init scripts will be needed at some point to.


> Doubt you want the last sed to determine success of the whole function

Bah, sed actually hardly returns anything but 0 when the file is writable and the command syntax is correct. But yeah, i will add a "return 0" to make it clear.


I will wait for you to agree/disagree about the "test both ROOT and non-ROOT" point before submitting an updated eclass.
Comment 4 TGL 2005-05-02 01:19:15 UTC
> Testing both ROOT and / seems safer to me for the case there is a
> DEPEND but no RDEPEND and X11 is installed only on the / system. 

...or also when the ROOT system has a recent (/usr) X11 but the build system uses an old one. That may happen more often.
Comment 5 Donnie Berkholz (RETIRED) gentoo-dev 2005-05-02 01:22:18 UTC
Any references in other ebuilds to stuff on the filesystem without ROOT in pkg_* functions are 99% likely to be broken too, and should have bugs filed. When using ROOT, does portage install DEPENDs to / or ROOT?

It looks like the current eclass will produce broken results on a system where / is /usr/X11R6 directory and ROOT is /usr/X11R6 symlink. It first tests /, which would result in PREFIX=/usr/X11R6, and never gets to testing ROOT.

Interesting point w/ the ! -L -- /usr/X11R6 being a dir and not existing would produce the same result. Although I think other various lower-level ebuild still meddle in /usr/X11R6, so at present this is a moot point. But you're right.

You have a point wrt ROOT having spaces, although that's not what I would imagine being a common situation. =)

If you think &&'s tabbed in get confused with the content of an if/then, feel free to tab the other content in farther. When I'm reading code, I only like to see the if and the fi, with everything else inside, including continuations.

You have another point wrt eclass names having hyphens.

Regarding the makefile fixer having FHS stuff in it, it could be a problem, however unlikely. But seriously, the real issue is that the x11-prefix eclass should only touch X11-prefix-related things and stay out of everyone else's business. This reduces unexpected results and keeps people from having to dig through the eclass functions to use them.

There's a bug with changing ProjectRoot in combination with using DESTDIR that Mike Harris has brought up (I think on the xorg list), so unless it's been fixed (which I haven't seen anything of), we can't do that.

Thanks for justifying what you've done so well.
Comment 6 TGL 2005-05-02 03:16:37 UTC
> When using ROOT, does portage install DEPENDs to / or ROOT?

If only in DEPEND, it will install only to /. 

# USE="-* X" ROOT=/tmp/test_root emerge -pv aquafont
>>> /tmp/test_root/tmp doesn't exist, creating it...
>>> /tmp/test_root/var/tmp doesn't exist, creating it...
>>> /tmp/test_root//var/cache/edb doesn't exist, creating it...
>>> /tmp/test_root//var/cache/edb/dep doesn't exist, creating it...
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild  N   ] media-fonts/aquafont-2.7-r2 +X 2,962 kB
Total size of downloads: 2,962 kB


> It looks like the current eclass will produce broken results on a system
> where / is /usr/X11R6 directory and ROOT is /usr/X11R6 symlink. It first 
> tests /, which would result in PREFIX=/usr/X11R6, and never gets to
> testing ROOT.

Yes, but imo that's not a broken result.  I've assumed that, for now, /usr/X11R6 was the safe fallback, and /usr was the prefix to use with care, only when we are sure it will work.  The point is that we don't know in the eclass whether X11_PREFIX will be used for compile-time stuffs (for instance as a path to headers) or runtime stuffs (for instance as prefix for the lib directory).  In the case of the / system using /usr/X11R6 and the ROOT system using /usr, that's true that X11_PREFIX=/usr/X11R6 is sub-optimal if it's only used for runtime stuffs. But it still work thanks to the symlink (which i assume will still be around as long as some profiles still accept <xorg-x11-6.8.2-rc3).  At the contrary, setting X11_PREFIX=/usr will break if it's used for some compile-time stuffs.

Actually, what i've first tried to do was to have two prefix variables: SLASH_X11_PREFIX and ROOT_X11_PREFIX.  That was more accurate for such cases. But it was also hardly usable, for instance when a Makefile uses a single variable for both the path where it looks for X11 headers and the one where it installs his own ones. Hence the merge in a single X11_PREFIX variable with a safe value. 

But your objection about pkg_* referencing non-ROOT files being very-likely broken is also true.  And the eclass may be btw, for instance in the following case:
 - a binary package is built with a given value for X11_PREFIX
 - it is then installed on a different machine: pkg_setup() is re-run, and change the value of X11_PREFIX
 - a pkg_{pre,post}{inst,rm} function do some stuff using X11_PREFIX in some file path... and this path is wrong

What i will to prevent that is:
 - in pkg_setup(), do not redefine X11_PREFIX if it's already in the environment (so that it is saved at build time, when it's safe to access the / filesystem, and the reloaded at install time, when it's not)
 - add a valid_x11_prefix() boolean function that checks that $X11_PREFIX is safe wrt. the current $ROOT (ie., it's not /usr if /usr/X11R6 is a real dir).
 - add a pkg_preinst() function which calls valid_x11_prefix(), and either print some fat eerrors about things being very likely broken if false, or even die (what do you prefer?).


> If you think &&'s tabbed in get confused with the content of an if/then,
> feel free to tab the other content in farther.

Or would it be ok to use only one tab for everything, but linebreak before "then" to separate the condition?

| if [ some quite long test ] \
|     && [ another one ]
| then
|     ...
|     do stuffs
|     ...
| fi

> Regarding the makefile fixer having FHS stuff in it, it could be a problem,
> however unlikely.

Yep, i would not have added that to an existing function, but since it was a new one, i thought it was ok to do whatever is commonly needed to fix that kind of makefiles.

> But seriously, the real issue is that the x11-prefix eclass should only touch 
> X11-prefix-related things and stay out of everyone else's business.

Hmmm... but it's so handy to not bother in ebuilds with the details of fixing all this crappy makefiles...

What about the following then?
 - in x11-prefix.eclass, a sed_x11_prefix() function that only does the s:/usr/X11R6:${X11_PREFIX}: job, and could also be used for kind of files.
 - in eutils.eclass, the fix_Imake_Makefile() function that does the other usual fixes (/usr/local, man suffix, man path, doc path).

The typical use-case would then become:
|   xmkmf || die
|   sed_x11_prefix Makefile || die
|   fix_Imake_Makefile || die

eutils.eclass is just for that kind of often needed random stuffs, no?


> There's a bug with changing ProjectRoot in combination with using DESTDIR

Oh, ok. (Note for later: do not try to teach spyderous his job, he knows it already ^_^)


> Thanks for justifying what you've done so well.

Thanks for taking it seriously :)
Comment 7 Donnie Berkholz (RETIRED) gentoo-dev 2005-05-02 10:00:24 UTC
> Yes, but imo that's not a broken result.  I've assumed that, for now, /usr/X11R6
> was the safe fallback, and /usr was the prefix to use with care, only when we 
> are sure it will work.

I suppose this means that in the worst-case scenario, we'll get the same behavior as before this eclass existed.

> - add a valid_x11_prefix() boolean function that checks that $X11_PREFIX is 
> safe wrt. the current $ROOT (ie., it's not /usr if /usr/X11R6 is a real dir).

I suppose it would be best if it died on either / or ROOT having /usr/X11R6 a dir, because we don't know where it will be installed.

> - add a pkg_preinst() function which calls valid_x11_prefix(), and either 
> print some fat eerrors about things being very likely broken if false, or even 
> die (what do you prefer?).

Die. But it would be a lot more helpful if we could die earlier, if possible.

> Or would it be ok to use only one tab for everything, but linebreak before 
> "then" to separate the condition?

Sure. Linebreaks are great.

> What about the following then?
> - in x11-prefix.eclass, a sed_x11_prefix() function that only does the 
> s:/usr/X11R6:${X11_PREFIX}: job, and could also be used for kind of files.
> - in eutils.eclass, the fix_Imake_Makefile() function that does the other 
> usual fixes (/usr/local, man suffix, man path, doc path).

It's fine by me to change any X11-related things in this eclass. Might be easier to just call the function fix_makefile() so people don't get confused and think they can only use it on Imakefiles or something silly.

As for eutils, I don't maintain that, so you can file another bug. =)
Comment 8 Donnie Berkholz (RETIRED) gentoo-dev 2005-05-17 15:27:52 UTC
I've just removed the last xorg-x11 version that didn't install everything to
/usr (6.8.0-r5). This might give us some simpler alternatives, such as
unconditionally installing to /usr.

Thoughts?
Comment 9 Petteri Räty (RETIRED) gentoo-dev 2005-12-01 10:52:44 UTC
There are probably many build systems relying on the /usr/X11R6 directory.
mozilla-firefox seems to be one of these so it will be a long time before we can
get rid of the symlink. Maybe we should instruct developers to manually delete
/usr/X11R6 and start testing to speedup things. I will certainly start to check
for this when stabling things.
Comment 10 Joshua Baergen (RETIRED) gentoo-dev 2005-12-01 12:08:01 UTC
FYI, xorg-7.0 ebuilds will force users to have a valid X11R6 symlink at install
time.  Maybe we can target the 7.1 release for removal?  That gives us a few
months...
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2006-03-31 19:05:17 UTC
Seems that nearly everything has been fixed without the need to add any sort of eclass.