On Thu, 2023-06-08 at 05:59 -0400, bill-auger wrote: > 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? I'll be quite honest, I just didn't think about it. As far as I see it, it is preferable to replace flashrom with flashrom-stable, and not because of just rust (although that would mean being simpler and lighter to build). Mostly because of being part of Coreboot and getting more development and support (as is already the case, flashrom-stable supports more target flashers and chips already), and also because the main developer from flashrom is actually now the one behind flashrom-stable (Nico Huber).
> > 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 what I could gather 1.1 is the "stable", I suppose some of the "instability "/quick pace is because of improvements that were stuck upstream and now are possible because of less bureaucracy. > > 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 haven't checked with the Arch packager, but I don't think they'll be replacing it any time soon - as that version is still technically the "official" flashrom. Should I still try to ask anyhow? > 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 > I just tested twice, with the two patches I sent applied it does compile fine time after time, the tarball is version-specific and stable so long you're pulling the same file. > * 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
