use GPL CUPS filter wrapper and revise all the ebuilds

[mehw]

This PR is a work in progress. As of now, it isn't ready to be merged. Commits will be added gradually, until the purpose of this work is complete.

Each current ebuild will be examined to choose the best scenario. Please, continue reading carefully.

Users may loose customizations of configuration files when upgrading/downgrading/reinstalling, see also #83 (comment):

• In my testing, exporting the CONFIG_PROTECT variable from inside an ebuild, adding the path to protect, didn't prevent a modified rc file from being replaced.
• Installing an env file into /etc/env.d (manually or via the ebuild), with CONFIG_PROTECT set to the path to protect, kept an rc file I modified from being replaced. But this doesn't trigger the dispatch-conf functionality, and the replacement file is lost.
• Setting CONFIG_PROTECT in /etc/portage/make.conf protects modified files the way we usually see for /etc. By far, this is the best.

Guidelines

NOTE: The parts between square brackets are optional.

• New ebuild naming convention: brother-NAME-VERSION[_pX][-rY].ebuild (discussed in add missing IUSE avahi in some metadata.xml files #83)
• Standard variables with default meaning (look above for the ebuild naming convention):
  • BR_PN: NAME
  • BR_PV: VERSION[-X] (X is the revision of the LPR driver)
  • MODEL: NAME in uppercase (may be used in place of BR_PN to form a path)
  • PAPER_TYPE: defaults to Letter, the use flag metric sets it to A4
  • DEST: /opt/brother/Printers/(BR_PN || MODEL)
  • CUPS_PPD_PATH: /usr/share/cups/model/brother
  • CUPS_FILTER_PATH: /usr/libexec/cups/filter
  • RC_FILE: LPR's rc configuration file name
  • PPD_FILE: CUPS' PPD file name
  • CUPS_WRAPPER: CUPS' filter wrapper file name
  • SRC_LPR_DIR: main LPR's driver path (something like ${S}/opt/brother/Printers/${BR_PN})
  • SRC_CUPS_DIR: main CUPS' driver path (something like ${S}/cupswrapper_gpl)
  • CUPS_INSTALL_SCRIPT: CUPS' install script file location (if such script is available)
• Copyright: after sensible changes, bump the year and assign the rights to Gentoo Authors
• Bump to EAPI=7
• Conform DESCRIPTION: find the most suitable template sentence
• Conform HOMEPAGE: usually http://support.brother.com
• Update SRC_URI: either CUPS, LPR, both, or none if not necessary (use source code whenever available)
• Update LICENSE: GPL-2 brother-eula no-source-code, where GPL-2 is for the cupswrapper source code
• Update IUSE: implement metric and debug when possible
• Update DEPEND, RDEPEND, etc.: add missing and remove unneeded dependencies
• Update the various ebuild phases according to the modifications introduced
• If possible/necessary, patch binary files to use DEST as location
• Fix script files to use standard/existing locations
• Update metadata.xml: indent and add missing use flags, also use generic descriptions
• Try to find the best convention to name .ppd files

TODO

• Verify inherit
• Verify KEYWORDS
• Verify IUSE (i.e. avahi)
• Verify pkg_setup

Doubts

• Where are the instruction on how to modify the rc configuration file (usually located in the /opt/brother/Printers/.../inf directory. brother-mfc6490cw-bin ships with a binary file to do this, what about the other models?
• How to deal with strange hardcoded paths like /etc/opt in brprintconflsr3 and /usr/local/Brother/inf/brPrintList.w.%s in braddprinter binary files of brother-dcp1510-bin?
• Can the .ppd files be compressed with gzip?

[stefan-langenmaier]

First of all, again, thank you very much for this detailed description. These guidelines are a very good idea and I think something that's really missing.

I don't know if you have ever noticed the script in:
https://github.com/stefan-langenmaier/brother-overlay/blob/master/generator/brother-generator.sh

This was in my opinion a really nice step to encode some guidelines that could then be enforced by generating/updating the ebuilds. Unfortunately this was then no longer maintained.

Each current ebuild will be examined to choose the best scenario

This is a sentence I'm a little bit afraid of. :) This sounds very ambitious. I would already be happy with a route that doesn't yield perfect ebuilds at the end but one that improves the ebuilds in multiple steps, each time a little bit. So if at a certain point you say, this is no longer worth the effort, there is already some improvement and you can just stop. I'm not sure to have expressed this properly. :)
What I want to say is that you can take as much time as you want, but from experience I know that perfection can sometimes be the biggest problem. ;-)

[mehw]

Hi @stefan-langenmaier,

I'm happy to hear from you!

I don't know if you have ever noticed the script in:
https://github.com/stefan-langenmaier/brother-overlay/blob/master/generator/brother-generator.sh

Thanks for that! I wasn't aware of it, because I didn't look around in the tree... I'll have a look into it.

I would already be happy with a route that doesn't yield perfect ebuilds at the end but one that improves the ebuilds in multiple steps, each time a little bit.

I really like to hear your opinion, I don't want to disfigure the brother-overlay doing too much. My purpose is to stay as faithful as possible to what was already there, fixing bugs on the way.

I believe that exploring the structure of each ebuild is required to ensure that the drivers are properly installed. I already found intertwined problems in ebuild phases that required an analysis of the packages (directory trees, binary and script/text files). A glimpse of that could be grasped in the net-printer/brother-{dcp1510,dcp1610w}-bin commit logs.

I felt more logical implementing guidelines, use of source code, and any required/remaining fix all at the same time, rather than splitting the work into different commits, as it was done at the beginning to deal with the issues repoman complained about. But I'm looking forward to discuss this matter to find the best lead to follow.

I can test only the brother-mfc6490cw-bin drivers, though, as the MFC-6490cw is the only brother peripheral I have.

Also, IMHO, there are two more things that could be done:

• Adding ebuilds for compatible models (i.e. net-printer DCP-1512, DCP-1615NW, DCP-1616NW, etc.).
• Keeping one ebuild revision to install the drivers from both LPR and CUPS binary packages, and one revision (the major) to install LPR from binary and CUPS from source code (there's no LPR source code available).

What I want to say is that you can take as much time as you want, but from experience I know that perfection can sometimes be the biggest problem. ;-)

Don't worry, the ebuilds won't be perfect, I promise... LOL

PS: I forced a push changing "CUPS filter wrapper" into "The CUPS driver" in the net-printer/brother-dcp1510-bin commit log.

[stefan-langenmaier]

Hi @mehw ,

I really like to hear your opinion, I don't want to disfigure the brother-overlay doing too much. My purpose is to stay as faithful as possible to what was already there, fixing bugs on the way.

No worries, disfiguring the overlay. :) And you also don't have to stay too faithful. I'd like to see different approaches. From my point of view the only limit is that I have to kind of understand the ebuilds so the overlay stays maintainable. So the other way around everything that makes it better/easier maintainable is highly welcome. :D

I believe that exploring the structure of each ebuild is required to ensure that the drivers are properly installed. I already found intertwined problems in ebuild phases that required an analysis of the packages (directory trees, binary and script/text files).

D'accord. Let me know when you are happy with the quality and I'll merge it.

I can test only the brother-mfc6490cw-bin drivers, though, as the MFC-6490cw is the only brother peripheral I have.

I know the problem. ;-) I don't have the hardware to test the requests of people so looking at the ebuild is often the only thing I can do.

So thanks again! Keep up the good work and let me know if you want input on a specific issue. I'll try to do my best. :)