[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Amfora and dependencies

On 4/10/21 12:27 PM, Nilesh Patra wrote:
> Yes,
> From my skimming through this one, it looks like the "item" var is of
> type "gofeed.Item" and when I check the README for the same here, I do
> not see any "Links" attribute here[1]
> This was strange, so I took a dab at go.mod, and this is what I found
> $ grep gofeed go.mod
> 	github.com/mmcdole/gofeed v1.1.0
> replace github.com/mmcdole/gofeed => github.com/makeworld-the-better-one/gofeed v1.1.1-0.20201123002655-c0c6354134fe
> i.e. it uses github.com/makeworld-the-better-one/gofeed instead of github.com/mmcdole/gofeed - the former is a "fork" of the latter.
> and the former has those "Links" attributes defined[2]
> Since we already have equivalent package of github.com/mmcdole/gofeed in
> the archive, packaging a fork would honestly be suboptimal and I doubt
> if it is going to be acceptable.
> The best solution - according to me would be to simply merge the changes
> from the fork to the real upstream so we can move ahead w/o hassle.
> In _worst_ case, we can maintain these changes in our package golang-github-mmcdole-gofeed
> Hopefully its maintainer would be OK with that.
And same thing also needs to be done for progressbar

Original - github.com/schollz/progressbar
Fork - github.com/makeworld-the-better-one/progressbar


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: