Open mehw opened 4 years ago
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. ;-)
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:
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.
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. :)
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 https://github.com/stefan-langenmaier/brother-overlay/pull/83#issuecomment-546726190:
CONFIG_PROTECT
variable from inside an ebuild, adding the path to protect, didn't prevent a modified rc file from being replaced./etc/env.d
(manually or via the ebuild), withCONFIG_PROTECT
set to the path to protect, kept an rc file I modified from being replaced. But this doesn't trigger thedispatch-conf
functionality, and the replacement file is lost.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.
Letter
, the use flagmetric
sets it toA4
/opt/brother/Printers/(BR_PN || MODEL)
/usr/share/cups/model/brother
/usr/libexec/cups/filter
${S}/opt/brother/Printers/${BR_PN}
)${S}/cupswrapper_gpl
)GPL-2 brother-eula no-source-code
, whereGPL-2
is for the cupswrapper source codemetric
anddebug
when possibleTODO
Doubts
/opt/brother/Printers/.../inf directory
.brother-mfc6490cw-bin
ships with a binary file to do this, what about the other models?/etc/opt
inbrprintconflsr3
and/usr/local/Brother/inf/brPrintList.w.%s
inbraddprinter
binary files of brother-dcp1510-bin?