Bugzilla Bug 102347

Well hidden on the German site (winace.de) there is a link to a UNACE v2.5 ELF
386 binary (the current version in portage is 1.2b-r1, incompatible with 2.0
archives)

Created an attachment (id=65822) [edit]
unace-bin-2.5.ebuild

Well, I tried to redo the tests from Bug 81958. It segfaults on ./unace {t,l,v}
bufoflow1.ace, works on bufoflow2.ace and reports "Header broken: Error while
reading archive" on dirtraversal{1,2}.ace.

I've posted another message on their forum, maybe this could be included in 
portage as a masked package? 

You can also find it here: http://www.winace.com/down.html
It's not that hidden ;)

Created an attachment (id=75505) [edit]
/usr/portage/licenses/ACE

I could not find a real license on WinAce's homepage, but this document could
go into the /usr/portage/licenses directory.

Created an attachment (id=75506) [edit]
unace-2.5.ebuild

An alternative ebuild for unace, which installs the unarchiver into /opt (like
rar).  I would also suggest to rename the old app-arch/unace to
app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package
reside in app-arch/unace.

The attached ebuild incorporates the above suggestion.

Best regards
Christian

Created an attachment (id=75507) [edit]
unace-bin-2.5.ebuild

An ebuild which installs unace into /opt and conforms to the naming scheme
suggested by Dick.

Created an attachment (id=75509) [edit]
/usr/portage/licenses/ACE

I just noticed that the .tgz contains a license file...

(In reply to comment #6)
> I would also suggest to rename the old app-arch/unace to
> app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package
> reside in app-arch/unace.

There's no reason for this. The ebuilds should be slotted, when they can live
side by side.

(In reply to comment #9)
> (In reply to comment #6)
> > I would also suggest to rename the old app-arch/unace to
> > app-arch/unace-gpl (as with unrar and unrar-gpl), and let this binary package
> > reside in app-arch/unace.
> 
> There's no reason for this. The ebuilds should be slotted, when they can live
> side by side.
> 

That would be fine for me, either.  How should one deal with the fact that both
the GPL version and the binary version use the same executable name?

(In reply to comment #10)
> That would be fine for me, either.  How should one deal with the fact that both
> the GPL version and the binary version use the same executable name?

The GPL version isn't of much use anyways, when you do not want to open very
dated ace archives exclusively, so I don't see why someone would want to keep
it. But it's the users decision how to deal with it.

Created an attachment (id=76286) [edit]
unace-2.5.ebuild

(In reply to comment #11)
> (In reply to comment #10)
> > That would be fine for me, either.  How should one deal with the fact that both
> > the GPL version and the binary version use the same executable name?
> 
> The GPL version isn't of much use anyways, when you do not want to open very
> dated ace archives exclusively, so I don't see why someone would want to keep
> it. But it's the users decision how to deal with it.
> 

This ebuild does not install unace into another slot as the GPL'd version. 
This is OK for me since I was not able to extract a single ACE archive using
the older version.

(In reply to comment #6)
> I would also suggest to rename the old app-arch/unace to
> app-arch/unace-gpl 
>


The old version does not seem very GPL to me...

The "file_id.diz" file contains the following notice: "the source may be
distributed and used, but I,Marcel Lemke, retain ownership of the copyrights to
the source."... There does not seem to be any other mention to a licence. There
is nothing about GPL, nothing about being free to modify the source and
redistribute it... even the "may be distributed and used", does not mean
much...

It is important to separate the source from the binary version, so we should
name the new binary ebuild "unace-bin", as the original reported did, and keep
"unace" for the source version... (which we should keep, as it is working -not
on recent archives, indeed-, and as... well, it is the source version...).

But did anyone tried to contact Marcel Lemke, the author of both versions,
about maybe distributing newer versions of the source code (under a more
precise licence)?

(In reply to comment #13)
> The old version does not seem very GPL to me...
>

Sorry, it is indeed GPL... I just saw bug #92846 :/

This is now in the sunrise overlay:
http://gentoo-sunrise.org/svn/reviewed/app-arch/unace-bin/unace-bin-2.5.ebuild

thanks to peper.

*** Bug 139398 has been marked as a duplicate of this bug. ***

*** Bug 139788 has been marked as a duplicate of this bug. ***

just got a bunch of archives for which gpl version says: "File compressed with
unknown method. Decompression not possible.", so maybe ressurect old binary
unace? maybe in ~ slots, or masked (if there still exists exploitable bugs).

unace-bin-2.5.ebuild in sunrise overlay works for amd64.

Can someone merge this with the main portage tree?

(In reply to comment #20)
> Can someone merge this with the main portage tree?

I second that.  I must also stress that I do not see the point in having the
GPL'ed unace version in portage.  It is practically useless as it is not able
to extract most ACE archives (in fact, I was not able to extract a single ACE
archive with it).

This is also the reason why I'm for renaming "unace-bin" to simply "unace" in
the overlay.  There is no need for having both versions installed at the same
time.

As a compromise, the current "unace" could be "unace-gpl" (as "unrar-gpl"), and
the overlay's "unace-bin" could become "unace".

But it seems I am just warming up an old discussion...

that ebuild in the sunrise overlay is just plain terrible

added as unace-2.5