Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

[James Le Cuirot]

On Mon, 17 Apr 2017 22:53:45 +0100
James Le Cuirot  wrote:

> If you've been wondering why I've been quiet of late (you have,
> right?!) then this is partly why. I'm not sure why I spent so long on
> an eclass that hardly anyone uses but it's utilised by many of my old
> favourite games.
> 
> The main bug that it fixes is one I filed a report for 10 years ago!
> There were also several duplicates. If you want something done...
> 
> I realised part way through that I didn't have any multi-disc games
> that use this eclass any more. A former friend of mine lost my second
> UT99 disc with the high resolution textures. I couldn't rewrite the
> eclass without testing it thoroughly so I wrote a brand new "comi"
> (Curse of Monkey Island) ebuild for use with ScummVM! I'll get this
> committed when these changes go in. I've also revised all the
> Descent-related packages.

Merged with the suggested fixes.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpzdnqnXskZF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

[James Le Cuirot]

On Tue, 18 Apr 2017 07:51:58 +0200
Ulrich Mueller  wrote:

> > On Mon, 17 Apr 2017, James Le Cuirot wrote:  
> 
> > If you've been wondering why I've been quiet of late (you have,
> > right?!) then this is partly why. I'm not sure why I spent so long
> > on an eclass that hardly anyone uses but it's utilised by many of my
> > old favourite games.  
> 
> Wouldn't this be a good time to rethink the whole concept? By all our
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
> the last remnant in the tree using PROPERTIES="interactive".

mgorny makes good points, it is indeed not quite that simple.

I didn't actually notice the --accept-properties=-interactive feature
until just now, that's pretty cool.

Although I agree it should be avoided, there may be other uses for it
in future. I'd still like to go ahead with my lgogdownloader plan
(probably via a new src_fetch) and that may need it for entering
credentials on rare occasions though there are other possibilities.

> Maybe the eclass could be replaced by a utility that extracts the ISO
> image and places it into DISTDIR, so that ebuilds could use regular
> non-interactive unpacking? The additional disk space used shouldn't be
> an argument any more with today's large disks.

Don't assume everyone has such huge disks. ;) My main system isn't bad
but that doesn't mean I want to waste the space on something like this.
Many have written optical media off but I still have two big flight
cases full of discs of various kinds nearby.

No one is forced to use this stuff and it is possible to use it in a
non-interactive manner similar to how you suggest. You can copy the
files from the disc(s) and point CD_ROOT to this location in a
per-package env file.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpDGHji1Ztv1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

[Michał Górny]

On wto, 2017-04-18 at 07:51 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 17 Apr 2017, James Le Cuirot wrote:
> > If you've been wondering why I've been quiet of late (you have,
> > right?!) then this is partly why. I'm not sure why I spent so long
> > on an eclass that hardly anyone uses but it's utilised by many of my
> > old favourite games.
> 
> Wouldn't this be a good time to rethink the whole concept? By all our
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
> the last remnant in the tree using PROPERTIES="interactive".
> 
> Maybe the eclass could be replaced by a utility that extracts the ISO
> image and places it into DISTDIR, so that ebuilds could use regular
> non-interactive unpacking? The additional disk space used shouldn't be
> an argument any more with today's large disks.
> 

I think the eclass supports multiple different CD variants (releases),
including poorly made copies, copy-protected media... I don't think you
can create a file with stable checksum out of them in any sane way.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

[Ulrich Mueller]

> On Mon, 17 Apr 2017, James Le Cuirot wrote:

> If you've been wondering why I've been quiet of late (you have,
> right?!) then this is partly why. I'm not sure why I spent so long
> on an eclass that hardly anyone uses but it's utilised by many of my
> old favourite games.

Wouldn't this be a good time to rethink the whole concept? By all our
standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
the last remnant in the tree using PROPERTIES="interactive".

Maybe the eclass could be replaced by a utility that extracts the ISO
image and places it into DISTDIR, so that ebuilds could use regular
non-interactive unpacking? The additional disk space used shouldn't be
an argument any more with today's large disks.

Ulrich


pgpfDfWl956ja.pgp
Description: PGP signature

[gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

[James Le Cuirot]

If you've been wondering why I've been quiet of late (you have,
right?!) then this is partly why. I'm not sure why I spent so long on
an eclass that hardly anyone uses but it's utilised by many of my old
favourite games.

The main bug that it fixes is one I filed a report for 10 years ago!
There were also several duplicates. If you want something done...

I realised part way through that I didn't have any multi-disc games
that use this eclass any more. A former friend of mine lost my second
UT99 disc with the high resolution textures. I couldn't rewrite the
eclass without testing it thoroughly so I wrote a brand new "comi"
(Curse of Monkey Island) ebuild for use with ScummVM! I'll get this
committed when these changes go in. I've also revised all the
Descent-related packages.