| View previous topic :: View next topic |
| Author |
Message |
zigford
n00b
Joined: 16 Feb 2005
Posts: 23
|
 Posted: Sat May 19, 2018 11:22 pm Post subject: Trouble with Custom ebuild and dependency from overlay |
 |
|
I'm creating my first ebuild to do things the gentoo way, but it relies on a package in another overlay.
Here is my ebuild: https://github.com/zigford/gentoo-zigford/tree/master/net-misc/onedrive
And it relies on the DMD compiler which is in the dlang overlay.
I've manually installed it on my machine using layman, and the ebuild works if I manually install the dependencies and merge it with ebuild, but when I add my repo with layman and attempt to get emerge to installed the deps, I get:
| Code: |
emerge: there are no ebuilds to satisfy "=dev-lang/dmd-2.0.78".
(dependency required by "net-misc/onedrive-1.1.1::zigford" [ebuild])
(dependency required by "net-misc/onedrive" [argument])
|
Anyone with more experience be able to give me a hand and point out if/what I'm doing wrong?
Many thanks
_________________
----------------------------------------
Say hi to your mum for me |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21623
|
| Posted: Sun May 20, 2018 12:38 am Post subject: |
|
|
You could use $PV to generate the server-side filename, so that this line does not need to change with each release.
There is no such license registered in Portage. You probably want GPL-3.
Does this package require that the D compiler be installed just to run the package?
This looks odd. Usually, if a program uses dev-db/sqlite at runtime, it is because it is linked to it and uses the shared object from sqlite. If so, then you need dev-db/sqlite installed at build time too.
These two sed statements could be folded into one. You might be better served using $PV here, so that the version you give it adjusts automatically with new releases.
As for your reported problem, what is the output of emerge --pretend --verbose dev-lang/dmd ; emerge --info? It looks like Portage cannot find the dmd package. Are you sure the overlay that provides it is properly configured? |
|
| Back to top |
|
|
zigford
n00b
Joined: 16 Feb 2005
Posts: 23
|
| Posted: Sun May 20, 2018 6:10 am Post subject: |
|
|
Many thanks for your detailed reply and comments on the ebuild.
I'll fix up the license and use $PV as you recommend.
As for the build vs runtime requirements, I get your point about including $DEPEND in $RDEPEND. I'll fix that up as I just left it from copying the basic ebuild from the wiki.
And sqlite is most likely a build time requirement as you suggested and I just made the wrong call.
Here is the output as requested:
| Code: |
$ emerge --pretend --verbose dev-lang/dmd
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-lang/dmd-2.080.0:2.080::dlang USE="selfhost -dmd-2_067 -dmd-2_068 -dmd-2_069 -dmd-2_070 -dmd-2_071 -dmd-2_072 -dmd-2_073 -dmd-2_074 -dmd-2_075 -dmd-2_076 -dmd-2_077 -dmd-2_078 -dmd-2_079 -doc -examples -gdc-6_4_0 -ldc2-0_17 -ldc2-1_1 -ldc2-1_2 -ldc2-1_3 -ldc2-1_4 -ldc2-1_5 -ldc2-1_6 -ldc2-1_7 -ldc2-1_8 -static-libs -tools" ABI_X86="(64) -32" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
* IMPORTANT: 1 news items need reading for repository 'dlang'.
* Use eselect news read to view new items.
$ emerge --info
Portage 2.3.36 (python 3.5.5-final-0, default/linux/amd64/17.0/desktop/gnome/systemd, gcc-6.4.0, glibc-2.25-r11, 4.9.95-gentoojesse x86_64)
=================================================================
System uname: Linux-4.9.95-gentoojesse-x86_64-Intel-R-_Core-TM-_i5-4670_CPU_@_3.40GHz-with-gentoo-2.4.1
KiB Mem: 8083128 total, 1185160 free
KiB Swap: 7869436 total, 7868604 free
Timestamp of repository gentoo: Tue, 15 May 2018 21:00:01 +0000
Head commit of repository gentoo: 6e6ab4a23126925f021bf2cf37c598af713709d9
sh bash 4.4_p12
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
app-shells/bash: 4.4_p12::gentoo
dev-java/java-config: 2.2.0-r4::gentoo
dev-lang/perl: 5.24.3-r1::gentoo
dev-lang/python: 2.7.14-r1::gentoo, 3.5.5::gentoo
dev-util/cmake: 3.9.6::gentoo
dev-util/pkgconfig: 0.29.2::gentoo
sys-apps/baselayout: 2.4.1-r2::gentoo
sys-apps/sandbox: 2.13::gentoo
sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake: 1.11.6-r3::gentoo, 1.15.1-r2::gentoo
sys-devel/binutils: 2.29.1-r1::gentoo
sys-devel/gcc: 6.4.0-r1::gentoo
sys-devel/gcc-config: 1.8-r1::gentoo
sys-devel/libtool: 2.4.6-r3::gentoo
sys-devel/make: 4.2.1::gentoo
sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers)
sys-libs/glibc: 2.25-r11::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts:
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24
zigford
location: /var/lib/layman/zigford
masters: gentoo
priority: -900
dlang
location: /var/lib/layman/dlang
masters: gentoo
priority: 50
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=haswell"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=haswell"
DISTDIR="/usr/portage/distfiles"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_AU.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli colord crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo exif fam flac fortran gdbm gif glamor gles gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg multilib nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support readline samba sdl seccomp spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wayland wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" RUBY_TARGETS="ruby22 ruby23" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
|
_________________
----------------------------------------
Say hi to your mum for me |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun May 20, 2018 12:17 pm Post subject: |
|
|
| Hu wrote: | | This looks odd. Usually, if a program uses dev-db/sqlite at runtime, it is because it is linked to it and uses the shared object from sqlite. If so, then you need dev-db/sqlite installed at build time too. |
That does not mean you need it in DEPEND as the op has inferred, which is equivalent to BDEPEND, ie CBUILD, not runtime CHOST. [1]
It just means it needs to be an LDEPEND, or in Gentoo terms (iirc) it needs an ABI subslot operator in RDEPEND. (I don't think a slot dependency does it, but might be wrong on both counts.)
For clarity: I use BDEPEND and LDEPEND to mean what BSD ports call BUILD_DEPENDS and LIB_DEPENDS, because I'm lazy, and prefer to think of link-dependencies; and occasionally other libs.
I'm fairly certain that Gentoo DEPEND is equivalent to BUILD_DEPENDS, based on conversations with zmedico in bug reports.
--
[1] For newbs: no, not CTARGET; that only ever applies to toolchain packages, such as compilers, binutils or objutils. It does not mean the machine the compiler will run on, CHOST, but the machine it will build for, once running. (Consider: if they are the same, it will be able to function as a native compiler.)
No other type of package's build-configuration ever pays attention to CTARGET; tools designed to handle the build-process included. They only need to pay it mind at runtime if building toolchain packages; but the in-use toolchain is what changes, not the build-system tool.
Evaluation is essential at build-time, ime. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21623
|
| Posted: Sun May 20, 2018 3:43 pm Post subject: |
|
|
As I understand it, with the ebuild as it was when I commented on it (ignoring OP's subsequent responses to my feedback), if sqlite is in RDEPEND and not in DEPEND, then that is declaring that the build should succeed when running the following: | Code: | emerge --unmerge dev-db/sqlite
emerge --buildpkgonly net-misc/onedrive |
When called with --buildpkgonly, emerge is obligated to make available packages in DEPEND, but not packages in RDEPEND. If net-misc/onedrive can be built without sqlite installed, but requires sqlite to run, then the original ebuild declarations were correct. This is typically only true for packages that want to run sqlite's command line programs. For packages that want to link to sqlite's shared object, the shared object and the headers need to be available at build time, and the shared object needs to be available at runtime. To declare that, sqlite needs to be in both DEPEND and in RDEPEND. If the ebuild language were more granular, we could specify that the sqlite libraries are in RDEPEND and sqlite headers and sqlite libraries are in DEPEND. The ebuild language is not that granular, so we instead specify only sqlite in both places.
OP: your original output says that =dev-lang/dmd-2.0.78 is not found. Your output from my request says that Portage would install =dev-lang/dmd-2.080.0. I should have told you to try emerge --pretend --verbose =dev-lang/dmd-2.0.78. However, based on what you have shown, my guess is that the dlang overlay has ceased to offer =dev-lang/dmd-2.0.78 in preference to the newer =dev-lang/dmd-2.080.0. Your existing ebuild insists on a specific version, and if the dlang overlay no longer provides that version, your ebuild will abort as you showed in the first post. I do not know what is changed between those versions, but if you want to assume that the newer dmd can build the program, change your DEPEND+RDEPEND to be: | Code: | DEPEND="
dev-lang/dmd
dev-util/dub
dev-db/sqlite
"
RDEPEND="${DEPEND}
net-misc/curl
" |
You may need to modify the USE flag dependency on dub. I doubt that leaving it as originally shown is correct if we change the dmd version in use, but I do not know what to put in its place. For now, I have dropped that qualifier, which is probably wrong in the general case, but might be enough to let you proceed in this specific case. We can revisit it if you have more problems. |
|
| Back to top |
|
|
zigford
n00b
Joined: 16 Feb 2005
Posts: 23
|
| Posted: Mon May 21, 2018 7:54 am Post subject: |
|
|
Thanks again, for persisting.
I've got it working now and it was down to a good 'ole typo. I believe that onedrive could be compiled with any/many of the current, older and future versions of dmd, however the dub package must be installed with a USE flag corresponding the the DMD version installed. I couldn't (with my current knowledge) work out an elegant way to dynamically write this in an ebuild, so I decided for the quick and dirty method of just tying it to one specific version of dmd, that way I can require the exact corresponding use flag for dub.
Anyhow, the typo was in the version of DMD I specified:
This
| Code: |
=dev-lang/dmd-2.0.78
|
Changed to
| Code: |
=dev-lang/dmd-2.078.3
|
has resolved it.
_________________
----------------------------------------
Say hi to your mum for me |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon May 21, 2018 2:19 pm Post subject: |
|
|
@Hu: the problem with that is that DEPEND applies to CBUILD, not to the runtime CHOST.
(this I am sure of, after confirmation on bugzilla from zac, several years ago.)
If you're building on your machine for your machine, it's the same thing; for every other situation (and for build-systems in general) it's borked.
I'm pretty sure portage is aware of the difference between CBUILD and CHOST, however. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21623
|
| Posted: Tue May 22, 2018 1:31 am Post subject: |
|
|
Yes, DEPEND is insufficiently granular for accurately describing cross-compilation. That does not mean you can omit build-time dependencies from DEPEND as you suggested above. | steveL wrote: | | That does not mean you need it in DEPEND as the op has inferred, which is equivalent to BDEPEND, ie CBUILD, not runtime CHOST. [1] |
Build time dependencies need to be expressed in two parts: packages which provide programs executed as part of the build and packages which provide data consumed by the build. The former must be executable. The latter need not be. As you say, in native compilation, this distinction can be glossed over since packages are not split out as -tools, -devel, and -libs subpackages. HDEPEND is meant to handle this issue. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue May 22, 2018 1:38 pm Post subject: |
|
|
| Hu wrote: | Yes, DEPEND is insufficiently granular for accurately describing cross-compilation. That does not mean you can omit build-time dependencies from DEPEND as you suggested above. | steveL wrote: | | That does not mean you need it in DEPEND as the op has inferred, which is equivalent to BDEPEND, ie CBUILD, not runtime CHOST. [1] |
Build time dependencies need to be expressed in two parts: packages which provide programs executed as part of the build and packages which provide data consumed by the build. The former must be executable. The latter need not be. As you say, in native compilation, this distinction can be glossed over since packages are not split out as -tools, -devel, and -libs subpackages. HDEPEND is meant to handle this issue. |
Trouble is, that doesn't.
HDEPEND is for CHOST dependencies in ROOT that are not needed at runtime (like headers.) At least, that's what I recall from the long discussion on bugzilla where I had to explain the CBUILD/CHOST/CTARGET thing yet again. It took ages to get people like mgorny to see what I was on about, whereas ofc spanky knew what I was talking about, but didn't think it worth explaining to anyone.
DEPEND must be CBUILD, or nothing works. Given that it is BDEPEND, you cannot also use it for CHOST sanely (until it is in turn running as a CBUILD: not the situation under discussion, and when it is, we'll be discussing the exact same things.)
I thought that was established, since before I got zmedico to agree to that statement ("DEPEND is CBUILD") on bugzilla, several years ago.
I can't believe it is still being used for CHOST as well as CBUILD ; while I trust you, I would ask you to confirm that.
Perhaps they've rebastardised HDEPEND somehow (tho if so, that's a terrible idea.) I know mgorny wanted to make it apply to CBUILD on the basis that it is the CHOST, which ofc it is not. (Nomenclature matters.) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed May 23, 2018 12:54 am Post subject: |
|
|
| steveL wrote: | | Perhaps they've rebastardised HDEPEND somehow |
Thanks for the link.
As feared, they've fscked it up royally. Basically mgorny has continued on his hissy-fit that a "new BDEPEND" is needed (he was calling it HDEPEND for ages, because of his confusion mentioned above.)
zmedico and spanky both agreed years ago that it is an incredibly stupid idea to change what DEPEND means according to EAPI, especially given years of expert developer knowledge all built up using DEPEND as BDEPEND.
Good luck explaining that change-in-meaning according-to-EAPI, to newbs.
Perhaps that's why he's so keen on continually obsolescing perfectly good EAPIs. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21623
|
| Posted: Wed May 23, 2018 1:23 am Post subject: |
|
|
| steveL wrote: | | Hu wrote: | | HDEPEND is meant to handle this issue. |
Trouble is, that doesn't.
HDEPEND is for CHOST dependencies in ROOT that are not needed at runtime (like headers.) At least, that's what I recall from the long discussion on bugzilla where I had to explain the CBUILD/CHOST/CTARGET thing yet again. It took ages to get people like mgorny to see what I was on about, whereas ofc spanky knew what I was talking about, but didn't think it worth explaining to anyone. |
That is not the interpretation I get from the man page shipped with =sys-apps/portage-2.3.24-r1: | Code: | HDEPEND
This should contain a list of all packages that are required to
be executable during compilation of this program (aka host
buildtime dependencies). These are usually tools, like inter-
preters or (cross-)compilers.
This variable is new in experimental EAPI 5-hdepend and will be
installed into the host system. (See section Cross-compilation
for more information.) |
Its choice of "host system" is unfortunately confusing, since it does seem to be meant as the "native" system, which is more traditionally called CBUILD. | steveL wrote: | | DEPEND must be CBUILD, or nothing works. |
Given the historically ambiguous usage, I would argue that DEPEND must be applied to both CBUILD and CHOST at the same time, or you cannot count on anything working. DEPEND is fundamentally inadequate for cross-compilation because it is ambiguous whether its author is describing packages to provide natively executable tools on the build system or is describing packages to provide headers/libraries appropriate to the CHOST system. Guessing it as CBUILD probably breaks less than guessing it as CHOST, since RDEPEND atoms (for shared libraries needed at runtime on CHOST) may cause the right result in the CHOST root, albeit for the wrong reason.
As a reminder, I'm only in this thread because you told OP to remove a much-needed DEPEND relation in a way that would seem to work in the common case (due to the package manager merging RDEPEND early, but only if not using --buildpkgonly), but was technically wrong. I have no stake in ebuild cross-compilation support.
Perhaps a clean sweep is in order. Define two new variables, one for CBUILD dependencies and one for CHOST dependencies. If both new variables are unset, then both are default-initialized to $DEPEND for backward compatibility. Ebuild maintainers who want to support cross-compilation properly can define both of those two new variables with correct contents. Maintainers who do not care, and ebuilds which are abandoned, can use the fallback, which will usually do more work, but will be functional (assuming the dependent packages are themselves cross-compilable). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed May 23, 2018 6:50 am Post subject: |
|
|
| Hu wrote: | | If both new variables are unset, then both are default-initialized to $DEPEND for backward compatibility. |
It is very exceptional that packages are needed in both.
Many packages in the mv overlay are already converted to EAPI=7 (for many it is not yet possible due to the stupid EAPI tests in trivial eclasses like readme-gentoo-r1 or meson which are not yet updated).
In the majority of cases, DEPEND really remained the same, since most things which would require moving are part of the base system and thus typically not listed in any *DEPEND.
For a few things, it is not clear to me whether they should be in BDEPEND or DEPEND or both, e.g.:
- x11-base/xorg-proto. On the one hand, as header files these should probably be in BDEPEND. But on the other hand, the content of the files is perhaps host-specific, so perhaps they should be in DEPEND and perhaps even only in DEPEND.
- bison, yacc, etc: They must be executed on the build host, hence BDEPEND. But on the other hand, they might need to include/generate host-specific headers.
- sys-devel/gettext: Similar problems. E.g. the binary msg-format on the build-host might produce big-endian although small-endian might be required on the host (or vice versa).
But apart from these cases, surprisingly few changes were necessary. Most changes happened in eclasses (e.g. git-r3.eclass automatically puts git into BDEPEND instead of DEPEND for EAPI=7).
Altogether, in view of this small number of necessary changes, the introduction of BDEPEND was perhaps not so stupid. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed May 23, 2018 5:17 pm Post subject: |
|
|
| Hu wrote: | | As a reminder, I'm only in this thread because you told OP to remove a much-needed DEPEND relation in a way that would seem to work in the common case (due to the package manager merging RDEPEND early, but only if not using --buildpkgonly), but was technically wrong. I have no stake in ebuild cross-compilation support. |
Sure, but as stated, zac has categorically stated that "DEPEND is CBUILD" years ago, so again, I think clarity is needed here. | Quote: | | Perhaps a clean sweep is in order. Define two new variables, one for CBUILD dependencies and one for CHOST dependencies. If both new variables are unset, then both are default-initialized to $DEPEND for backward compatibility. Ebuild maintainers who want to support cross-compilation properly can define both of those two new variables with correct contents. Maintainers who do not care, and ebuilds which are abandoned, can use the fallback, which will usually do more work, but will be functional (assuming the dependent packages are themselves cross-compilable). |
Why do you think I have been banging on about BDEPEND and LDEPEND for so many years?
LDEPEND is the critical runtime dependency that needs to be added, and DEPEND is already BDEPEND (in portage codespace, which is what matters.)
No-one wants to admit that there is such a glaring hole in the spec, since inception, because it begs the question why no-one ever even noticed, even though I don't care about that, only about correct specification of the most basic dependency-type known. | mv wrote: | | the introduction of BDEPEND was perhaps not so stupid. |
Sure, finally separating out is better; just bear in mind mgorny wanted to call it "HDEPEND" for "host dependency" without actually knowing what that meant. I kept banging on about BDEPEND wrt CBUILD vs CHOST (and how neither is CTARGET), but bear in mind it already exists as "DEPEND" in portage, and has done since the beginning.
So leave DEPEND out of the picture, as Hu mentioned above, and talk about BDEPEND by all means, but the missing piece is LDEPEND, which we still do not have.
CHOST: LDEPEND installed in ROOT, pre-build. add HDEPEND for CHOST headers (not required at runtime)
CHOST: RDEPEND, PDEPEND: installed in ROOT, before the package can be considered installed; the former before it is in use as a BDEPEND, the latter before the end of the emerge.
CBUILD: BDEPEND (or DEPEND in portage) required for build.
If you simply add LDEPEND, you have everything you need, and you no longer need the vast majority of subslot operators, making ebuilds cleaner as well as easier to understand and reuse as metadata.
It would finally make ebuilds match what upstream developers have in mind, as well as admins dealing with library dependencies on a routine basis.
Instead, mgorny is pushing ahead with changing what DEPEND means according to EAPI (which does nothing for the functionality of the format, but much to lose valuable experience) and missing the chance to correctly specify the missing runtime dependency-type that everyone knows we actually need, in ports long before portage was even conceived.
All this because people don't like who makes the technical point (simply from looking at the prior art) or are so unwilling to admit they missed it, to the extent that they would rather pretend they never even heard it?
Welcome to the nubskool; 2.0 upgraded. yay.
Have fun with all those deliberately-unneeded subslot operators, stoking McCreesh's ego, and ignoring: the sterling work ferringb did, the prior art, the wasted time in revdep-rebuilds, and the lost opportunity to track lib-dependencies at installation much more sanely and far more usefully.
Borken by design, because ego. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu May 24, 2018 9:27 am Post subject: |
|
|
| steveL wrote: | CHOST: LDEPEND installed in ROOT, pre-build. add HDEPEND for CHOST headers (not required at runtime)
CHOST: RDEPEND, PDEPEND: installed in ROOT, before the package can be considered installed; the former before it is in use as a BDEPEND, the latter before the end of the emerge.
CBUILD: BDEPEND (or DEPEND in portage) required for build. |
Isn't this essentially EAPI=7, the only difference being that LDEPEND is named DEPEND, and that HDEPEND should apparently be added to BDEPEND (indluding the corner cases I mentioned which are in fact all a mixture of HDEPEND and BDEPEND)?
Whether it is clever to use the name DEPEND instead of LDEPEND (hence changing the previous meaning of DEPEND) is disputable, but the argument that this requires the least changes to existing ebuilds seems to be correct (at least from the experience I made).
| Quote: | | and you no longer need the vast majority of subslot operators |
I don't see how a "cleaner" LDEPEND might help with this.
| Quote: | | deliberately-unneeded subslot operators [...] wasted time in revdep-rebuilds |
revdep-rebuild is hack. A useful hack in the lack of anything else, but it fails to detect important cases when ABI-changes are not (or cannot) be accompanied by version bumps of libraries. Examples for "are not" have fortunately decreased, but still there are upstreams who refuse to bump. And there are still examples for "cannot" when you do not have classical C libraries (xorg, perl, python, ...). Subslots are a hack, too, at least how they are currently implemented. (The reason for the pushed --dynamics-deps=n is simply the broken implementation of subslots.) Anyway, it is more reliable than revdep-rebuild, since at least one can specify something in the ebuild if required. An extension of revdep-rebuild by installing additional "hint"-files or something similar might have been the better solution, but the chance to fix this is long gone, I am afraid. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
