Re: [gentoo-dev] Rewriting bash-completion.eclass
2011/9/8 Michał Górny mgo...@gentoo.org: Done. Also, added an example. If nobody has further objections, I'll commit this today. -- Best regards, Michał Górny Dunno but shouldn't there be two fields one for AUTHOR and one for MAINTAINER, Also in the code do not use the autotols-utils... but just plain default.
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 8 Sep 2011 09:52:02 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: 2011/9/8 Michał Górny mgo...@gentoo.org: Done. Also, added an example. If nobody has further objections, I'll commit this today. -- Best regards, Michał Górny Dunno but shouldn't there be two fields one for AUTHOR and one for MAINTAINER, Also in the code do not use the autotols-utils... but just plain default. AUTHOR is optional. I don't see a reason to keep the same info in both; AUTHOR is rather useful when someone else maintains the eclass. Example updated. -- Best regards, Michał Górny bash-completion-r1.eclass Description: Binary data signature.asc Description: PGP signature
[gentoo-dev] Rewriting bash-completion.eclass
Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 14:48, Michał Górny napsal(a): Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Tom
Re: [gentoo-dev] Rewriting bash-completion.eclass
On 09/01/2011 07:48 AM, Michał Górny wrote: Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? De-facto maintainer signing off, your ideas have been read and well-accepted by myself. Carry on as you see fit, IMO. -Jeremy
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Ah, forgot about stats. dobashcompletion() with two args is used a lot of times. BASHCOMPFILES is used in ONE ebuild in gx86. BASHCOMPLETION_NAME is used in 4-5 ebuilds. We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 15:15, Michał Górny napsal(a): On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátalscarab...@gentoo.org wrote: That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Ah, forgot about stats. dobashcompletion() with two args is used a lot of times. BASHCOMPFILES is used in ONE ebuild in gx86. BASHCOMPLETION_NAME is used in 4-5 ebuilds. We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. how about new calls completely? dobashcomp newbashcomp As even if you fix main tree you can't ensure that you won't mess with some overlay (silently as it would not be seen by default). I would then go proactively and fix the packages inheriting the bashcomp eclass and when done just mark the eclass as dead. Tom
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 1 Sep 2011, Michał Górny wrote: I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I'd rather keep this in a separate bash-completion-2.eclass. We shouldn't start moving all do* and new* functions from other eclasses to eutils, but keep it somewhat modular. Ulrich
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 1 Sep 2011 15:27:12 +0200 Ulrich Mueller u...@gentoo.org wrote: On Thu, 1 Sep 2011, Michał Górny wrote: I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I'd rather keep this in a separate bash-completion-2.eclass. We shouldn't start moving all do* and new* functions from other eclasses to eutils, but keep it somewhat modular. So, here it goes. However, I'm not sure if that even deserves a dedicated function as the destination is pretty constant. -- Best regards, Michał Górny bash-completion-r1.eclass Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
On 15:20 Thu 01 Sep , Tomáš Chvátal wrote: Dne 1.9.2011 15:15, Michał Górny napsal(a): We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. As even if you fix main tree you can't ensure that you won't mess with some overlay (silently as it would not be seen by default). I would then go proactively and fix the packages inheriting the bashcomp eclass and when done just mark the eclass as dead. Yes, please stop breaking backwards compat without version bumps to a new eclass. It's just as annoying in an eclass as in a shared library. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpe4A1WUfHEv.pgp Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 1 Sep 2011, Michał Górny wrote: So, here it goes. However, I'm not sure if that even deserves a dedicated function as the destination is pretty constant. # @BLURB: A few quick functions to install bash-completion files # @DESCRIPTION: # A few simple functions to help installing bash-completion scripts. Looks somewhat redundant. Omit DESCRIPTION? Ulrich
