[Solved] Basic ebuild hacking help for updating freac ebuild

[jasn]

I had installed the fre:ac audio converter from the betagarden overlay in a previous installation. For my new system, since the ebuilds hadn't been updated, I thought I could just take the ebuilds for media-sound/freac, and its dependencies, media-libs/freac-cdk, and x11-libs/smooth, copy them to my local overlay and rename them, to update and install them. (I naively thought this mostly because I haven't a clue about ebuild syntax..)

I realized that in addition to changing the ebuild name, I also needed to update the SRC_URIs, as well. For the smooth library, I renamed the betagarden ebuild, smooth-0.8.72.0_pre2.ebuild, to smooth-0.8.74.0_pre4.ebuild, and edited the SRC_URI to directly point to the SF source code archive download link of, https://sourceforge.net/projects/smooth ... re4.tar.gz. The library then appeared to emerge correctly.

For the betagarden ebuilds of freac-20151115.ebuild, and freac-cdk-20151115.ebuild, I eventually renamed them to freac-20180913.ebuild, and freac-cdk-20180913.ebuild, respectively, (after trying naming variations that included an _alpha1 append, but for which the ebuild [...] digest command rejected the ebuild name). I also edited the SRC_URI to point to the direct link for the github source code archive download links listed here. Unfortunately the freac-cdk emerge fails with the simplest of errors indicating to me, that my hasty rename hacking doesn't work;

Code: Select all

The source directory '/var/tmp/portage/media-libs/freac-cdk-20180913/work/freac-cdk-20180913' doesn't exist

because of course the actual source directory is;

Code: Select all

/var/tmp/portage/media-libs/freac-cdk-20180913/work/freac-cdk-1.1-alpha-20180913

I'd appreciate it if someone could look over the betagarden ebuilds above, and the source archive download links, and suggest what I should actually be renaming these ebuilds to in my local overlay, and what SRC_URIs I should be using, in order to properly install everything.

TIA

[Tony0945]

No need to rename them unless there is a conflict within the overlay. I was going to say official tree but you can always eliminate that with a line

Code: Select all

official-dir/official-name::gentoo

to package.mask.
i.e.

Code: Select all

sys-fs/udev-init-scripts::gentoo

On my system only overlay init-scripts can be emerged.

OTOH, if the package and version exists and is installed, and you want to massage the package, then, yes, you have to do more surgery like repacking the package and putting it on a local web server, or doodling with the config in _src_configure() or some other renaming thing.
I'm having a similar problem. https://forums.gentoo.org/viewtopic-t-1 ... ight-.html

I'm not familiar with your application so I can't be specific.

I thought I could just take the ebuilds for media-sound/freac, and its dependencies, media-libs/freac-cdk, and x11-libs/smooth, copy them to my local overlay and rename them,

Did the version change? Then you can keep the name and just renumber it.
Is the package the same but will not longer build? Then keep the same name and number in your local overlay and mask the other by repo name as in the examples above.

Code: Select all

# eix freac
No matches found

Doesn't seem to be a conflict.

[Hu]

By default, the expected unpack path is derived from the package name and version. Upstream is expected to package things with the proper directory structure for this to work transparently. When they don't, the ebuild maintainer must either override $S to set the actual path or repackage upstream's sources so have the expected path. For well-behaved packages, SRC_URI can be automatically derived from the package version, allowing a rename to be sufficient to switch to the new version. The linked smooth ebuild already has an override for $S on line 43. Follow that style for the failing ebuilds. Use variables wherever you can, so that the override has a chance of working with other Portage build directories, other package versions, etc.

[jasn]

Thanks for the responses to the thread Tony and Hu..

Tony, I apologize for not making clear that this was a new system installation, and that freac isn't available in portage, or any other overlay. I was simply trying to hack together an install of the most recent version of the program, using an outdated ebuild. I've edited my original post to reflect that this was a new system installation.

Hu, thanks for pointing out how to change the working directory within the ebuild, and after doing so for each of the freac and freac-cdk ebuilds, I was able to emerge everything.

Jason

[Tony0945]

No need to apologize!