On 24/09/13 07:42PM, corey bruce wrote: > Hi there Adam Hello Corey,
> [...] Please do not open new threads for each answer that you're sending but instead just reply to the previous mails in order to keep everything in one place. > Thanks > Corey Cheers, Chris > > On 10/9/24 11:58 pm, Brian Allred wrote: > > Sep 10, 2024, 04:46 by cdfro...@gmail.com: > > > > Hello everyone, I hope you are all doing well > > > > I just wanted to talk about the discussion about my package > > sm64ex-bin, I was informed to chat about it on the mailing list so > > I wanted to make sure I was in the right place. I will admit the > > initial issue frustrated me and felt a little targeted especially > > when most of my other bin packages use binaries from my > > repository but I wanted to discuss the issue and resolve any > > allegations of slander that was put on with no factual evidence to > > provide when I have been a long time package developer on the AUR > > and a longer time developer on Github and Gitlab which I use now. > > > > It isn't against the rules to compile from source and host the > > binaries on your own repository especially if the original > > repository does not provide any or doesn't provide them for > > specific architectures, I wanted to create a bin package for a > > project for user to use and enjoy the project without needing to > > wait for compiling times especially on Raspberry pi devices every > > time while also bundling it with my launch scripts if needed,. For > > example NZPortable-bin binaries are provided from my git > > repository for the nzportable-bin package but I am officially > > supported by the team to do so and it's a bit harsh to slander me > > with assumptions that I am a bad actor with no evidence, it's also > > pretty rule and a bit insulting to my credibility. > > > > All I ask is to have the ability to re upload my package and > > continue to maintain the bin package for sm64ex-bin for all the > > users who use it including myself, I am happy to talk about any > > upstanding issues and fix any concerns if there is any. > > > > > > Thank you > > > > > > Corey Bruce > > > > Hey Corey, > > > > From a user perspective, my main concern would be that the source used > > to compile the hosted binary file is available. If you're literally only > > hosting a binary file, then I expect the source code used to compile > > said file would be the original source - in this case from the sm64ex > > repo. If you're including source modifications during the build process, > > then I would expect the modified source to be available, and ideally > > (though not a hard requirement), I'd prefer the binary file hosted as a > > GitHub/GitLab release asset on the same repo. > > > > The other issue I could see is if a compiled form of sm64ex no longer > > requires the user to provide the game ROM. If your sm64ex-bin package > > can be installed and run without the user ever providing a ROM file, > > then I can understand an AUR admin being hesitant to host that package. > > > > I'm not privy to any previous comments or allegations, so I can't speak > > to those. And I'm not an AUR admin or Arch staff member. But again, from > > a user perspective, as long as the source used to compile the binary > > file is available, it doesn't really bother me where the file is hosted > > or who's hosting it. I don't see a big difference between you hosting > > the file and maintaining the AUR package versus an original developer > > doing so. > > > > Hopefully this issue can be resolved amicably. > > > > Brian Allred
signature.asc
Description: PGP signature
