Re: d-i, pulling in fdisk-udeb
On Thu, Oct 02, 2003 at 09:51:08AM +0200, Sven Luther wrote:
> On Wed, Oct 01, 2003 at 12:41:49AM +0100, Richard Hirst wrote:
> > On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote:
> > > On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote:
> > > >> Make it depend on "partitioning-program", and make both fdisk-udeb and
> > > >> parted-udeb "Provide[s]:" that. Should solve the problem.
> > > > No, it won't. anna could still install just parted-udeb since
> > > > that would satisfy the dependency. If partitioner depends on a
> > > > particular udeb, it needs to Depend on the particular udeb.
> > >
> > > If parted-udeb is unusable on a particular platform, I'd take it it was never
> > > built/uploaded for that platform at all...?
> > I didn't mean to say that parted was unusable on hppa. It exists
> > and probably works ok. But parted cannot be used for creating the
> > 'f0' partition that palo needs.
> Have you ever considered asking the parted upstream author or filling a
> bug report against the parted debian package, for this particular
> feature request.
> I have been doing some parted work, but know nothing about the hppa
> specific needs, but if you explain it to me, i may be willing to add the
> needed support to libparted or something.
I've put quite a bit of effort in on parted in the past too, relating to
GPT partition tables. The issue is that parted tends to identify
partition types by their content, and not by the 'type' byte in an msdos
partition table. This is partly because parted handles many different
partition table formats, they don't all have a 'type' byte, and parted
tries to present a uniform interface. GPT tables, for example, have a
32 byte GUID instead. So parted lets you say "this partition is for
linux swapspace", and for msdos tables it knows to set the type to 82
and for GPT it knows to use some specific GUID. Some special types or
GUIDs are exposed to the parted interface as 'flags' you can set. e.g.
if you set the hp_service 'flag', it will write the
PARTITION_HPSERVICE_GUID in a GPT table.
To fix this issue, I'd need to expose a new flag through the parted i/f,
so you could "set palo on", or similar. For msdos tables it would know
that meant to set type=f0. For other partition table types it would
have no effect. Alternatively I could introduce a new command
completely for setting a partition table 'type' to some user-specified
hex value. But what would that do for non-msdos tables? Having an
interface where you can type in 32 byte GUIDs seems silly to me.
As to why I havn't done anything about this.. there really hasn't been
any incentive as we have cfdisk on hppa which works fine and has a nice
easy to understand interface. If d-i ends up dictating that I have to
use parted, or eventually presents a nicer interface to parted than its
current cli one, then it'll be worth worrying about.