* iso/live/hddimg images, cdrecord, burnia, the future
@ 2024-05-16 13:47 Ross Burton
2024-05-16 15:53 ` [OE-core] " Richard Purdie
0 siblings, 1 reply; 4+ messages in thread
From: Ross Burton @ 2024-05-16 13:47 UTC (permalink / raw
To: openembedded-core
Hi,
oe-core has an ‘iso’ image type that creates ISO9660 images for booting from a CD/DVD. At the moment this is implemented using cdrtools (aka cdrecord) but this has “legal complications” meaning a number of mainstream distributions don’t use cdrtools [1], and the project is - generously speaking - only somewhat maintained as part of an uber-repository at https://codeberg.org/schilytools/schilytools. None of this is ideal.
Back when cdrtools moved to the CDDL and the distros decided this was not acceptable, Debian created a fork called cdrkit based on the last GPL release. This has no licensing issues but is now abandoned, notably the Debian packaging of cdrkit has a number of patches which are not upstreamed.
Against this background, the libburnia project has been quietly busy since ~2007. This is a fresh implementation with wrappers that behave like cdrtools, is GPLv2 licensed, and still actively maintained[2].
I’m proposing that we switch the ISO image type to using libburnia instead of cdrtools. I’ve verified that this is just a s/mkisofs/xorrisofs/ in image-live.bbclass and the resulting ISO is almost identical and boots successfully (in a qemu).
I’m _also_ proposing that we admit that ISO images and Yocto have very limited overlap, and instead of moving the libburnia recipes from meta-filesystems (libburn, libisofs, libisoburn) we just document that ISO generation requires meta-filesystems to be added. The big catch here is that live images are actually ISOs, but for this I believe that very few people actually use the live/hddimg images and this won’t be missed from core. My entirely unresearched guess is that some people use hddimg but they don’t need to: a traditional partitioned disk image can be written to a disk/stick/card and works just as well to boot, and the initramfs-based installer should work in that environment too.
Thoughts?
Ross
[1] https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy
[2] https://dev.lovelyhq.com/libburnia/libisoburn/commits/branch/master
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [OE-core] iso/live/hddimg images, cdrecord, burnia, the future
2024-05-16 13:47 iso/live/hddimg images, cdrecord, burnia, the future Ross Burton
@ 2024-05-16 15:53 ` Richard Purdie
2024-05-16 15:57 ` Ross Burton
0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2024-05-16 15:53 UTC (permalink / raw
To: ross.burton, openembedded-core
On Thu, 2024-05-16 at 13:47 +0000, Ross Burton via lists.openembedded.org wrote:
> oe-core has an ‘iso’ image type that creates ISO9660 images for
> booting from a CD/DVD. At the moment this is implemented using
> cdrtools (aka cdrecord) but this has “legal complications” meaning a
> number of mainstream distributions don’t use cdrtools [1], and the
> project is - generously speaking - only somewhat maintained as part
> of an uber-repository at
> https://codeberg.org/schilytools/schilytools. None of this is ideal.
>
> Back when cdrtools moved to the CDDL and the distros decided this was
> not acceptable, Debian created a fork called cdrkit based on the last
> GPL release. This has no licensing issues but is now abandoned,
> notably the Debian packaging of cdrkit has a number of patches which
> are not upstreamed.
>
> Against this background, the libburnia project has been quietly busy
> since ~2007. This is a fresh implementation with wrappers that
> behave like cdrtools, is GPLv2 licensed, and still actively
> maintained[2].
>
> I’m proposing that we switch the ISO image type to using libburnia
> instead of cdrtools. I’ve verified that this is just a
> s/mkisofs/xorrisofs/ in image-live.bbclass and the resulting ISO is
> almost identical and boots successfully (in a qemu).
>
> I’m _also_ proposing that we admit that ISO images and Yocto have
> very limited overlap, and instead of moving the libburnia recipes
> from meta-filesystems (libburn, libisofs, libisoburn) we just
> document that ISO generation requires meta-filesystems to be added.
> The big catch here is that live images are actually ISOs, but for
> this I believe that very few people actually use the live/hddimg
> images and this won’t be missed from core. My entirely unresearched
> guess is that some people use hddimg but they don’t need to: a
> traditional partitioned disk image can be written to a
> disk/stick/card and works just as well to boot, and the initramfs-
> based installer should work in that environment too.
>
> Thoughts?
I'm fine with moving out iso but hddimg has proven to be used by more
that you'd think. It also has fairly complex code in core which if
we're keeping it, I'd like a way to test it...
Cheers,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [OE-core] iso/live/hddimg images, cdrecord, burnia, the future
2024-05-16 15:53 ` [OE-core] " Richard Purdie
@ 2024-05-16 15:57 ` Ross Burton
2024-05-16 16:25 ` Alexander Kanavin
0 siblings, 1 reply; 4+ messages in thread
From: Ross Burton @ 2024-05-16 15:57 UTC (permalink / raw
To: Richard Purdie; +Cc: openembedded-core
On 16 May 2024, at 16:53, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> I'm fine with moving out iso but hddimg has proven to be used by more
> that you'd think. It also has fairly complex code in core which if
> we're keeping it, I'd like a way to test it…
Unfortunately an hddimg is an ISO on a FAT, so they’re tangled together. hddimg are _horrible_...
Ross
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [OE-core] iso/live/hddimg images, cdrecord, burnia, the future
2024-05-16 15:57 ` Ross Burton
@ 2024-05-16 16:25 ` Alexander Kanavin
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Kanavin @ 2024-05-16 16:25 UTC (permalink / raw
To: ross.burton; +Cc: Richard Purdie, openembedded-core
On Thu, 16 May 2024 at 17:57, Ross Burton via lists.openembedded.org
<ross.burton=arm.com@lists.openembedded.org> wrote:
> > I'm fine with moving out iso but hddimg has proven to be used by more
> > that you'd think. It also has fairly complex code in core which if
> > we're keeping it, I'd like a way to test it…
>
> Unfortunately an hddimg is an ISO on a FAT, so they’re tangled together. hddimg are _horrible_...
We can also do it with a two step deprecation process. I'm going to
write a proposal for formalising that, as there are quite a few more
things I want out of core, but the key to getting there is knowing who
the users are and how they're using those things. The only way to find
out is to give them deprecation warnings.
Alex
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-05-16 16:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-16 13:47 iso/live/hddimg images, cdrecord, burnia, the future Ross Burton
2024-05-16 15:53 ` [OE-core] " Richard Purdie
2024-05-16 15:57 ` Ross Burton
2024-05-16 16:25 ` Alexander Kanavin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.