/usr/lib64 - why?

[apurkrt]

I used to use 32bit gentoo for quite some time. Here the situation was simple - there was only /usr/lib.

Now, I am using 64bit version. And I dislike the fact that libraries reside in /usr/lib64.

Why? Because from time to time, I like to try git versions of some program in portage (e.g. xfce4-panel), and install it manually. And I have to run configure with "--libdir=/usr/lib64" (in addition to --prefix=/usr).

I guess there is no way this would change, but anyway - what are the reasons behind /usr/lib64? Why we did not stick with the good old /usr/lib?

[fedeliallalinea]

https://wiki.gentoo.org/wiki/Project:AM ... lib_layout

[Hu]

Why not update the corresponding ebuild, which would both handle this for you and avoid confusing Portage by dropping unmanaged files in system directories?

[apurkrt]

Why not update the corresponding ebuild, which would both handle this for you and avoid confusing Portage by dropping unmanaged files in system directories?

Yeah, it is the "clean way". But it is too much of a hassle (for me at least) to maintain a custom ebuild, and if I know (and I do know) that there are no other files going to be installed than those that are already in the filesystem, it is so much easier to just do "make install".

[apurkrt]

Also, is there a way how to achieve "merge only"? Since when I am experimenting (small changes to one file), I do not want the whole source be rebuilt, it takes too much time. I want to (re)build by hand (make) just the files that were changed and then install by merge.. Or how the workflow would be in such case?

[arnvidr]

Code: Select all

ebuild something.ebuild qmerge

See: man ebuild

[erm67]

Why not update the corresponding ebuild, which would both handle this for you and avoid confusing Portage by dropping unmanaged files in system directories?

Yeah, it is the "clean way". But it is too much of a hassle (for me at least) to maintain a custom ebuild, and if I know (and I do know) that there are no other files going to be installed than those that are already in the filesystem, it is so much easier to just do "make install".

Well it's even easier just configure to install in the /usr/local/ prefix, no lib64 problems, just make install and you can always clean up the system in a moment by erasing /usr/local/*

Actually I recently started to use ~/.local prefix instead of /usr/local, it is just great

[apurkrt]

Code: Select all

ebuild something.ebuild qmerge

See: man ebuild

Thanks. I looked at the ebuild manpage, but it is hard to work with. This is what I found (perhaps there is an easier way and someone could point to it).

You have to

Code: Select all

ebuild /usr/portage/xfce-base/xfce4-panel/xfce4-panel-4.14.1.ebuild unpack

first (quite a long command)

It unpacks into /var/tmp/portage/xfce-base/xfce4-panel-4.14.1/work (quite a long and impractical path, in my opinion)

the real sources are at /var/tmp/portage/xfce-base/xfce4-panel-4.14.1/work/xfce4-panel-4.14.1/panel (even longer path)

now it is still not git source, but then you would change some files, invoke

Code: Select all

ebuild /usr/portage/xfce-base/xfce4-panel/xfce4-panel-4.14.1.ebuild install qmerge

and then you have your modified xfce4-panel installed.

Quite a hassle. And it is still not the git version and the modified source resides int /var/tmp - not a good path to begin with.

It is so much easiear to unpack or git clone to your home dir,

Code: Select all

configure --prefix=/usr --libdir=/usr/lib64

then edit the source, and "make install" to overwrite whenever you want to try the new version.

And it was even easier when there was no "--libdir=/usr/lib64" required

Or perhaps, again, there is some better way how to utilize ebuild to test your own source. But I do not know about it.

[erm67]

use
https://wiki.gentoo.org/wiki//etc/porta ... e.provided

and install to /usr/local

[apurkrt]

use
https://wiki.gentoo.org/wiki//etc/porta ... e.provided

and install to /usr/local

Thanks, good idea. Though if one knows there are no file differences between the installed package and a modified version, I think it is actually better to do what I do - install over with make install, configured with --prefix=/usr --libdir=/usr/lib64. You can not easily uninstall from /usr/local if you have more than one modified package and do not want to delete everything.

[asturm]

No, for system files, it is always better to use an ebuild in your local overlay. This is dead simple to operate.

[apurkrt]

No, for system files, it is always better to use an ebuild in your local overlay. This is dead simple to operate.

Is there a simple how to/would you care to provide the steps necessary to do?

[John R. Graham]

[topic=1070842]Here's the workflow[/topic] I use for local development using git and emerge—using emerge exclusively for modifications to the live filesystem. I never run "make install", although I may run make in the development directory repeatedly before I commit changes.

- John

[apurkrt]

[topic=1070842]Here's the workflow[/topic] I use for local development using git and emerge—using emerge exclusively for modifications to the live filesystem. I never run "make install", although I may run make in the development directory repeatedly before I commit changes.

- John

Thanks a lot, interesting reading.

[apurkrt]

Just to make myself clear - I do "make install" of the modified version only after I installed the original package with emerge, i.e. I am just overwriting files that are already in the database of installed files. Imo it is still the best thing to do when testing changes to the source. Doing emerge always recompiles the whole package from scratch, afaictl.

[ct85711]

Yes, emerge will recompile from scratch, hence why when doing your own modifications, to use the ebuild command (the low level commands that does the actual work). The ebuild command, you can execute the individual stages (like uncompress and configure, then do your changes, then have ebuild continue though compile/merge afterwards. Emerge is more of a high level command (for easier usage) that ends up running the ebuild commands for you...

[Hu]

You are welcome to that opinion, but I think you are treading on thin ice. Your method assumes that:

• The version for which you run make install by hand installs exactly the same set of files that were installed by Portage. No files are new.
• Any changed files are ABI compatible with the originals installed by Portage.
• Nothing in the system will care that the installed files now fail equery check.

If you checked out the same commit from upstream as was used for the release you installed, and you configured with the same options, and you applied by hand any patches that the Gentoo ebuild would have applied, then the first two are pretty safe assumptions. If you don't do all those things, then you have a more involved problem determining whether those assumptions are safe. The much safer course would be to tell Portage to unpack and patch the source, then you hand edit the files you want to change, then you tell Portage to build and install the result. When you like the results of your changes, create a user patch to implement them, so that rerunning emerge does not discard your changes.

[Phoenix591]

Is there a simple how to/would you care to provide the steps necessary to do?

to convert an existing ebuild to a live ebuild that tracks git, you don't need to add/change much at all, in fact many live ebuilds already in portage are identical to the latest non git versions, just with an if statement

Code: Select all

if [[ ${PV} == "9999" ]] ; then
	inherit git-r3 distutils-r1
	EGIT_REPO_URI="https://github.com/<developer>/${PN}.git"
	KEYWORDS=""
else
	inherit distutils-r1
	SRC_URI="https://github.com/<developer>/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
	KEYWORDS="~amd64 ~x86"
fi

Basically, add git-r3 to the inherit line (add one if there isn't one already), and set the KEYWORDS to nothing. That alone will grab the master branch from the repo URI, if you want to follow a specific branch or commit you can set EGIT_BRANCH or EGIT_COMMIT respectively

see the git-r3 eclass for more info on things you can set/tweak

put the ebuild in your overlay/the package's category/packagename/packagename-9999.ebuild


If you don't already have an overlay, they're straight forward to setup

[John R. Graham]

Just to make myself clear - I do "make install" of the modified version only after I installed the original package with emerge, i.e. I am just overwriting files that are already in the database of installed files. Imo it is still the best thing to do when testing changes to the source. Doing emerge always recompiles the whole package from scratch, afaictl.

The vast majority of the packages I work on can be tested from the build directory, without the need to do a "make install". My workflow (in a dedicated project directory, by the way) goes something like this:

1. Edit some source code.
2. Run make.
3. Do some testing.
4. Repeat steps #1 through #3 as necessary.
5. When satisfied with the changes, commit them. With the [topic=1070842]ebuild structure I described here,[/topic] the updates to the package are available to emerge as soon as the changes are committed. (That would be the -9998 version, by the way.)
6. Emerge the package to install it on the live filesystem.

I realize that there are some exceptions (packages that need to be installed to properly test), but is your current use case actually one of them? In any case, I'm with Hu: the compile time is a small price to pay for good installed file tracking and avoidance of breakage & cruft.

- John

[dmpogo]

I'd say that if you do manual installation, you are better of installing into /usr/local/