| Summary: | app-arch/ecm new ebuild | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hadrien Lacour <hadrien.lacour> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | jstein, yana |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/alucryd/ecm-tools | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
ebuild
New ebuild ecm-1.0.0.ebuild |
||
|
Description
Hadrien Lacour
2017-05-14 19:36:59 UTC
Created attachment 472616 [details]
ebuild
Thank you for the ebuild. Please add the header # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 see cat /usr/portage/skel.ebuild one can not know from the DESCRIPTION what the ebuild is about. Finally you can test the ebuild with repoman -d full. See also https://devmanual.gentoo.org/ebuild-writing/index.html You can ask the developer kindly to create release tags. This makes things easier. Would you like to proxy maintain the ebuild? see also https://www.archlinux.org/packages/community/x86_64/ecm-tools/ Thanks for the advice. >You can ask the developer kindly to create release tags. Well, the thing is that the upstream is dead. I still asked the Github repo proprietor. >Would you like to proxy maintain the ebuild? Sure. Does that mean I put myself as maintainer in metadata.xml? I think an overlay would fit best to host the ebuild at first. The best would be to create your personal overlay for it and put the metadata.xml there too. We try to add only maintained and "important" packages to the main tree. I do not expect that there are more than 5 gentoo users who would install this package today. Hence your personal overlay or another overlay would be ideal. The ebuild can be used and improved early by all gentoo users and it is easy to copy it to the main tree some day, if necessary. Here is a good start: https://wiki.gentoo.org/wiki/Overlay You may put a link here to your overlay, when it is online. Feel free to discuss your ebuild on IRC or the corresponding support channels. I see. If I created this bug, it's also to help users searching like me, since there's no other package that can do this. Jonas Stein, I disagree. I've just wanted to write an ebuild for this myself, but luckily I've searched it on bugs.gentoo.org before proceeding :-) This is a very important package for anyone who plays CD-based console games (mainly PlayStation) on an emulator. Sometimes your CDs are scratched to the point you can't dump them anymore, or you can't buy a CD anymore, and the only option to get that game is most likely by downloading an ECM file and decoding it from site like OpenEmu. There is a number of repositories that have this package: Homebrew (https://github.com/Homebrew/homebrew-core/blob/36387cce5baa181fb99528ecf346ded3ef5a4967/Formula/ecm.rb), Arch Linux (https://www.archlinux.org/packages/community/i686/ecm-tools/), FreeBSD ports/packages (https://svnweb.freebsd.org/ports/head/archivers/ecm/), even super-conservative Debian (https://packages.debian.org/jessie/ecm) has it. If maintenance burden is the issue to accept this ebuild into the tree, I can co-maintain this along with Hadrien. Please please please let this into the tree. If we have games-emulation/pcsxr in the tree, we should have ecm tools as well. That said, I'm not sure about the category (de facto it's mostly used for games, but actually it should belong to app-arch as it's a general compression algorithm for CD images and can be used with e.g. music CDs) and I strongly disagree with the package name (it should be ecm) and source (it should be sourced from https://web.archive.org/web/20091021035854/www.neillcorlett.com/downloads/ecm100.zip the same way Homebrew and FreeBSD do it). Also notice that FreeBSD puts it under archivers, which is analogous to Gentoo app-arch. >it should belong to app-arch Right. >I strongly disagree with the package name (it should be ecm) I guess. >(it should be sourced from https://web.archive.org/web/20091021035854/www.neillcorlett.com/downloads/ecm100.zip I really don't know. Is there a Gentoo policy about this (forks vs web archives)? >>I strongly disagree with the package name (it should be ecm)
> I guess.
Package name depends on the source: Debian, FreeBSD, Homebrew use original source (and thus the package is called ecm) and Arch Linux uses this ecm-tools fork, thus the package name.
What I dislike in this fork is unnecessarily changed binary names, removed crucial documentation about CD format and ECM compression (see format.txt in archive.org link), and that it's more complex than the original (it has two header files, tons of #ifs, again, compare the original and the ecm-tools git repo).
And ecm proved to be highly portable (Debian builds it for every arch out there, mips, arm, ppc, amd64, x86), and I'm not sure that ecm-tools fork has the same portability profile.
Created attachment 472908 [details]
New ebuild
Here's a corrected ebuild using the original upstream, and installing the furnished doc. Created attachment 472914 [details] ecm-1.0.0.ebuild Hadrien, I've updated your ebuild a bit. Changes: * removed app-arch/unzip from RDEPEND (it only needs unzip at build time, not at runtime) * changed LICENSE from GPL-3 to GPL-2+ (see gpl.txt and copyright notice in ecm.c) * added Gentoo Prefix support (tested on ~amd64-linux, ~x86-linux, ~x64-macos) * added arches that Debian builds as experimental * used PN/PV enviornment variables and versionator * marked amd64 and x86 as stable (I've just round-tripped a few CD ISOs on amd64) Repoman might be unsatisfied by ~x64-macos and ~amd64-linux keywords not being present for app-arch/unzip, but that's because Gentoo Prefix has an overlay with some of ebuilds overridden (incl. app-arch/unzip). BTW, this is not the first ebuild that sources from web.archive.org, check it out: https://github.com/gentoo/gentoo/search?utf8=✓&q=%22archive.org%22 Nice, but you should keep the 80 char linebreak. I've removed it because I don't see anyone doing that in the main tree. Well, it says here https://devmanual.gentoo.org/ebuild-writing/file-format/index.html that's it's better when possible. From #gentoo IRC: <yegortim`> hi, do we wrap lines longer than 80 chars with \ in the main tree? <yegortim`> e.g. https://618468.bugs.gentoo.org/attachment.cgi?id=472908 <yegortim`> i think there are obvious maintenance problems with this approach, but ebuild file format page (https://devmanual.gentoo.org/ebuild-writing/file-format/index.html) says "Where possible, try to keep lines no wider than 80 positions" [16:17] <grknight> yegortim`: no, the HOMEPAGE is invalid <yegortim`> thanks <grknight> yegortim`: yes, wrap them when it makes sense; don't try to be too creative :) grknight is an active Gentoo developer, so the answer is quite authoritative. I see. It was just bothering my autism a little when seeing emacs highlight it. I've overlooked two things: * DESCRIPTION isn't correct, see the original author's description: ECM (Error Code Modeler) lets you prepare CD image files (such as BIN, CDI, NRG, CCD, or similar) so that they'll compress far better in programs such as WinRAR. So you can use it with any CD encoding format, not just BIN. * there should be doc USE flag. I'll make these changes to ebuild and open a pull request against gentoo/gentoo GitHub repo in several hours. |
