Such existing flags to pass options to a script do still work. The existing
known flags are handled.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Will this change affect `__ocaml_requires_opts` / `__ocaml_provides_opts`?
I'm trying to work out how that works - I guess RPM must do some magic for
these?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1070 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1070#event-3114013687___
Rpm-maint mailing list
Lost between all the other discussion was an approval from @Conan-Kudo. I'm
don't know any better, and rpm-extras isn't going to happen *now* so I guess we
might just as well merge it.
Thanks @olafhering for all the work, and patience.
--
You are receiving this because you are subscribed to
@Conan-Kudo what I meant is not to release piece of junk, but start with just
this OCAML generators. Once there is something else to be called "stable",
release that as well. But not just random content which is there right now.
--
You are receiving this because you are subscribed to this
At this point in time, `rpm-extras` is set up to be a dumping ground. It's
_not_ set up with any kind of quality things, any process of rationalization of
scripts and such. Without that, we're just going to commit stuff in there
that's not even going to work.
For example, the ALT Linux brp
@ignatenkobrain This will be a crap situation to deal with in openSUSE, since
it's going to be a pain to make openSUSE keep this stuff in place correctly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai if you prefer this going away to rpm-extras, I'm willing to establish
releases, installation scripts, and so on and so forth.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Sorry about that, but full rewrite like this would be about the best time there
is for such a move. So it makes sense to at least consider that option right
now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Will you guys please discuss and perform any separation of language support in
a separate SR, please?!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Three problems with it:
>
> 1. It would be regressive to current functionality for no good reason.
> 2. We don't have a way of distributing this in any kind of reasonable
> fashion through rpm-extras.
> 3. IMO, That's not what rpm-extras is for. It's for staging things to
>
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1070#pullrequestreview-359353949___
@olafhering pushed 1 commit.
dddabb30a808a803d00d9543f09cf201eae85102 update OCaml requires/provides to
cover also cmx
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@olafhering pushed 1 commit.
9f04b41e653da201a6350b00482309d4be272519 update OCaml requires/provides to
cover also cmx
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ignatenkobrain Three problems with it:
1. It would be regressive to current functionality for no good reason.
2. We don't have a way of distributing this in any kind of reasonable fashion
through rpm-extras.
3. IMO, That's not what rpm-extras is for. It's for staging things to
eventually
> @ignatenkobrain No, there's no reason to move it there.
Why not? It is better to split language-specific things into a rpm-extras.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> +}
+#
+#
+usage() {
+echo >&2 "Usage: ${0##*/} -prov|-req [-f 'ocamlobjinfo cmd']"
+}
+#
+mode=
+ignore_implementation_a=()
+ignore_interface_a=()
+while test "$#" -gt 0
+do
+ : "${1}" "${2}"
+ case "${1}" in
+-prov) mode='prov' ;;
+
@ignatenkobrain No, there's no reason to move it there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> While we are on it, shouldn't we move these to rpm-extras?
That is up to you guys. But this must be a separate SR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
While we are on it, shouldn't we move these to rpm-extras?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
olafhering commented on this pull request.
> +}
+#
+#
+usage() {
+echo >&2 "Usage: ${0##*/} -prov|-req [-f 'ocamlobjinfo cmd']"
+}
+#
+mode=
+ignore_implementation_a=()
+ignore_interface_a=()
+while test "$#" -gt 0
+do
+ : "${1}" "${2}"
+ case "${1}" in
+-prov) mode='prov' ;;
+
Conan-Kudo requested changes on this pull request.
> +}
+#
+#
+usage() {
+echo >&2 "Usage: ${0##*/} -prov|-req [-f 'ocamlobjinfo cmd']"
+}
+#
+mode=
+ignore_implementation_a=()
+ignore_interface_a=()
+while test "$#" -gt 0
+do
+ : "${1}" "${2}"
+ case "${1}" in
+-prov) mode='prov' ;;
Dependencies between OCaml files containing native code are also tracked
by hashes, just like their bytecode counter parts.
OCaml native code files end with cmx, the relevent info is in cmx, cmxa
and cmxs files. Unlike all other OCaml files, cmxs files have ELF format.
OCaml has two variants of
23 matches
Mail list logo
