On Sat, 10 Oct 2015 10:43:29 -0700 Alec Warner <anta...@gentoo.org> wrote:
> On Sat, Oct 10, 2015 at 8:16 AM, Brian Dolbec <dol...@gentoo.org> > wrote: > > > On Sat, 10 Oct 2015 14:24:28 +0200 > > Fabian Groffen <grob...@gentoo.org> wrote: > > > > > On 10-10-2015 14:19:44 +0200, hasufell wrote: > > > > > +RDEPEND=" > > > > > + !libressl? ( dev-libs/openssl:0 ) > > > > > + libressl? ( dev-libs/libressl ) > > > > > + sys-libs/zlib > > > > > + net-libs/http-parser > > > > > > > > Please order deps alphabetically (I know I added libressl > > > > without reordering, but that was just to keep the diff as small > > > > as possible). > > > > > > Is this a policy or a preference? In case of the first, have > > > repoman do it for you. > > > > > > Fabian > > > > > > > > > > Please NO, repoman's code is still a mess, the last thing it needs > > is adding a bunch of code messing with ebuilds directly. Reporting > > is one thing, modifying ebuilds quite another. > > > > At Google the go team spent a bunch of time building different tools > for these purposes (which share code of course.) > > So there is a: > go compiler # compiles your code > go cmt # properly formats your code > go vet # finds common anti-patterns in your code > > I don't see why someone could not write an 'ebuild vet' or 'ebuild > fmt' tool; it doesn't have to start as a strict component of repoman > at all (although ideally it ends up there to be run automatically.) > > -A > Well, I meant it more for the current repoman code state. Once the re-write is complete, the structure and code will be in a much better state to simply pug in a module like you described. In the meantime, it would simply add to the complexity of the code and subsequently the rewrite. -- Brian Dolbec <dolsen>
