Re: ocaml-extlib minimal build
by Richard W.M. Jones
On Tue, May 26, 2020 at 11:19:11PM +0800, Andy Li wrote:
> Hi Richard,
>
> Thank you for looking into this.
>
> On Tue, May 26, 2020 at 6:51 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
> > I looked at the packages in Fedora which BR ocaml-extlib and it looks
> > like nothing uses these modules. Haxe seems to have a bundled copy of
> > extlib with these modules, some renamed, it's not very clear what's
> > going on.
>
> extlib was originally written by the same author as Haxe. Historically,
> Haxe bundled extlib, and it evolved a bit while extlib was taken over by someone
> else in the OCaml community.
> Later Haxe adopted using opam for dependency management and it puts its
> diverged bits of extlib into the "extlib-leftover" folder in Haxe's source code.
> Haxe 4.1 can only compile with the "minimal" extlib, because the files in
> "extlib-leftover" conflict with the "full" extlib.
>
> > So I think there are three plausible options here:
> >
> > (1) Use the minimal=1 flag, since nothing directly in Fedora should be
> > affected. But perhaps external users will care, or I made a mistake
> > in my analysis.
>
> For the record, Debian has just converted its extlib package from
> "full" to "minimal".
> The only affected package was "headache", but turnout the latest version of
> "headache" doesn't depend on extlib, so it was resolved by updating
> the "headache"
> package to its latest release.
>
> openSUSE also builds its extlib package in minimal mode.
This is the strongest argument for using minimal. We generally
attempt to stay close to what the other distros are doing because it
reduces friction for upstream developers.
> For external users, I have the impression that OCaml devs do not use system
> OCaml packages but only the OCaml compiler and opam.
I think it depends on the developer and use case. For example if
they're hacking on the compiler itself opam is likely the best option.
You can't really use system packages for that.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
4 years, 1 month
ocaml-extlib minimal build
by Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1837823
Hopefully I've CC'd this to everyone who has a package that
BuildRequires ocaml-extlib in Fedora.
As Andy pointed out in the bug report above, ocaml-extlib has two ways
to build it, and upstream recommends building using the "minimal"
variant. The difference is that the minimal variant omits certain
modules which conflict with OCaml modules found in the standard
library or in other packages.
Because of the way OCaml modules work, you cannot have a program with
two modules with the exact same name even if they come from different
packages - instead you should namespace modules, but extlib never did this.
The modules that are *removed* by setting minimal=1 are:
- Unzip
- UChar
- UTF8
I looked at the packages in Fedora which BR ocaml-extlib and it looks
like nothing uses these modules. Haxe seems to have a bundled copy of
extlib with these modules, some renamed, it's not very clear what's
going on.
So I think there are three plausible options here:
(1) Use the minimal=1 flag, since nothing directly in Fedora should be
affected. But perhaps external users will care, or I made a mistake
in my analysis.
(2) Build both extlib variants from single source.
(3) Do nothing.
Note that the professed aim of extlib upstream is to make itself
obsolete by including all the features in the standard library, so one
day in the perhaps distant future we will remove ocaml-extlib.
Let me know if you have any thoughts.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
4 years, 1 month
libutempter rebase to version 1.2.0
by Tomas Korbar
Hi guys,
later today i will rebase libutempter to version 1.2.0 in rawhide.
There is no soname bump and i checked that the abi is 100% compatible so i
do not expect
any issues. Still I wanted to give you info if something unexpected would
happen.
4 years, 1 month
Does the installer detects when a distro have already created BLS?
by Paul Dufresne
Well... it take time to me to get used to the Boot Loader Specification.
I am being lazy here... asking people on the mailing list rather than
trying to determine it myself.
After making an installation of Fedora, I begin to think:
Hey, I don't remember having seen the installer like detecting the use
of a previously installed /boot and/or /boot/efi partition, and tells me
that it will automatically use it by default.
But since with Boot Loader Specification, these are supposed to be
shared among distribution (maybe more likely a recent Fedora version
with an older Fedora version), it make sense that it should happens.
Maybe I did not seen it because I tend to erase the disk and begin from
scratch.
Still, rereading the specs, at:
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
I see these at the beginning:
"These directories are defined below the placeholder file system
|$BOOT|. This placeholder file system shall be determined during
/installation time/, and an fstab entry for it shall be created mounting
it to /boot. The installer program should pick |$BOOT| according to the
following rules:
* If the OS is installed on a disk with MBR disk label, and a
partition with the MBR type id of 0xEA already exists it should be
used as $BOOT.
* Otherwise, if the the OS is installed on a disk with MBR disk label,
a new partition with MBR type id of 0xEA shall be created, of a
suitable size (let's say 500MB), and it should be used as $BOOT.
* If the OS is installed on a disk with GPT disk label, and a
partition with the GPT type GUID of
bc13c2ff-59e6-4262-a352-b275fd6f7172 already exists, it should be
used as $BOOT.
* Otherwise, if the OS is installed on a disk with GPT disk label, and
an ESP partition (i.e. with the GPT type UID of
c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large
enough (let's say 250MB) and otherwise qualifies, it should be used
as $BOOT.
* Otherwise, if the OS is installed on a disk with GPT disk label, and
if the ESP partition already exists but is too small, a new suitably
sized (let's say 500MB) partition with GPT type GUID of
bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should
be used as $BOOT.
* Otherwise, if the OS is installed on a disk with GPT disk label, and
no ESP partition exists yet, a new suitably sized (let's say 500MB)
ESP should be created and should be used as $BOOT.
"
So the question is basically, does the installer make the check for
preexisting $BOOT ?
4 years, 1 month
