On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > As to why it should conflict with "vanilla" flashrom, because it is a fork > thereof and they share a lot of the core code and files - that I think that is > pretty obvious.
yes, i admitted that is obvious - but are both needed? - if they are duplicates, or if the new one supersedes the existing one, we should remove the one in [extra] - otherwise, we (you) should write a new wiki article, explaining why there are two packages of the same software, and why someone may prefer to use one or the other - so, i am asking those questions now - by conflicting with the extra package, it is suggesting that both packages should be available - so why keep two? - why are you not suggesting to remove the one in [extra] instead? On Thu, 08 Jun 2023 05:28:40 +0300 Wael wrote: > As for the rest, I've added the fixes you told me about - the 'patches' file > is > just one file with both of the patches (that I've added separately). > In any case, I'll also be contacting Nico Huber, being also the maintainer of > the AUR PKGBUILD. i was not asking you to do anything differently to the PKGBUILD - in that case, i would have shown you my version, which is good enough for now - my main suggestion was to ask the upstream why there are no stable tarballs from IRC: > <wael> I've applied the changes to flashrom-stable, it now builds from > tarballs > I've also clarified the reasons for packaging it (not just hte lack of > rust, > but also a better supportive development environment in the Coreboot > tree) if it is objectively "better", then there is no reason to keep the one in extra - but in that case, that suggests firstly, before doing _any_ of this, to contact the arch packager of the 'flashrom' package, and suggest to change the upstream source to the objectively "better" one - if accepted, then neither of us would need to do anything more - but perhaps the arch packager would have a valid argument against doing so - i am trying to determine now, what that objection might be (ie: what reason is there for parabola to keep both packages?) i was not asking you to build it from a tarball, in this case - that was only the general guideline - i already tried that - the tarball is not reproducible, so i abandoned that approach - if you ask the upstream "why do you not release stable tarballs?", that may be their answer: "because our VCS does not generate tarballs reproducibly" - that is all i was suggesting: to find out why i had to jump through such hoops, in order to make the source package reproducible - is yours? - try deleting the upstream tarball and running makepkg again - i think you will see that the checksum always fails sometimes building from a tarball is not possible (IMHO, this is that case); but in those cases, the package should be highly desirable to justify bending the rules about reproducibility and VCS builds, or else that software is best rejected, if the upstream will never publish tarball releases - over-all, that is what i was trying to determine * does it justify bending the rules? * can the upstream be convinced to do stable releases? * does it suggest removing the extra package? * can the arch packager be convinced to switch to the new upstream? _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
