| View previous topic :: View next topic |
| Author |
Message |
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
 Posted: Tue Oct 08, 2019 6:52 am Post subject: /usr/lib64 - why? |
 |
|
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? |
|
| Back to top |
|
 |
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 31287
Location: here
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22740
|
| Posted: Wed Oct 09, 2019 2:08 am Post subject: |
|
|
| Why not update the corresponding ebuild, which would both handle this for you and avoid confusing Portage by dropping unmanaged files in system directories? |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 5:47 am Post subject: |
|
|
| Hu wrote: | | 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". |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 7:49 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Wed Oct 09, 2019 9:48 am Post subject: |
|
|
| Code: | | ebuild something.ebuild qmerge |
See: man ebuild
_________________
|
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Wed Oct 09, 2019 10:12 am Post subject: |
|
|
| renergy wrote: | | Hu wrote: | | 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
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 10:32 am Post subject: |
|
|
| arnvidr wrote: | | Code: | | 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: | | 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: | | 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: | | 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. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Wed Oct 09, 2019 11:29 am Post subject: |
|
|
use
https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided
and install to /usr/local
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 11:35 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9312
|
| Posted: Wed Oct 09, 2019 11:49 am Post subject: |
|
|
| No, for system files, it is always better to use an ebuild in your local overlay. This is dead simple to operate. |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 12:10 pm Post subject: |
|
|
| asturm wrote: | | 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? |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10658
Location: Somewhere over Atlanta, Georgia
|
| Posted: Wed Oct 09, 2019 2:22 pm Post subject: |
|
|
Here's the workflow 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
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 2:29 pm Post subject: |
|
|
| John R. Graham wrote: | Here's the workflow 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. |
|
| Back to top |
|
|
apurkrt
Tux's lil' helper
Joined: 26 Feb 2011
Posts: 116
Location: Czechia, Europe
|
| Posted: Wed Oct 09, 2019 6:44 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Wed Oct 09, 2019 7:12 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22740
|
| Posted: Thu Oct 10, 2019 1:28 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Phoenix591
Guru
Joined: 17 Sep 2007
Posts: 493
|
| Posted: Thu Oct 10, 2019 10:40 am Post subject: |
|
|
| renergy wrote: |
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: |
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 |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10658
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu Oct 10, 2019 7:04 pm Post subject: |
|
|
| renergy wrote: | | 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:- Edit some source code.
- Run make.
- Do some testing.
- Repeat steps #1 through #3 as necessary.
- When satisfied with the changes, commit them. With the ebuild structure I described here, 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.)
- 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
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3441
Location: Canada
|
| Posted: Fri Oct 11, 2019 6:33 am Post subject: |
|
|
| I'd say that if you do manual installation, you are better of installing into /usr/local/ |
|
| Back to top |
|
|
|
Gentoo Chat
