Requesting official statement from developers

[ghost]

Open letter to @tuxce @Skunnyk @larchunix and other yaourt developers:

Yaourt has been the most popular AUR helper for quite some time in the past and has been referred to by many upstream developers for installations of packages from the AUR.

There have been many helpers that have effectively superseded yaourt since those times – in terms of features, security concerns, code quality and most importantly user support and feedback.

To many of these projects yaourt has been an inspiration and a useful metric to compare against. Now legacy of yaourt has been continued by yay.

There are still people using yaourt to this day and I think it is only fair to give an update on where the project is going officially.

Some of notable issues include:

• -Si sources PKGBUILD, code to do that is still there from 2010 to today instead of using SRCINFO that is intended to be used that way.
• Inability to correctly solve and build complex dependency chains Sync libraries and binaries from AUR before the package depending on them #186
• Inability to correctly build and install split packages Split packages dependencies not detected #85
• Exports extra variables preventing successful build process: aur-general, Building issue (movian-git) #309
• Performing partial upgrades on Arch Linux: since initial commit in 2008 till today by always splitting local db sync and upgrade action even when -Syu is specified on the command line.

Yaourt does not see much development in years with many issues unresolved and unanswered. Other popular helpers have provided an update in such and other cases and archived github repo so people don't mistakenly seek support, see links below grey items in the table for examples.

Please provide an update and thanks for your long-lasting contribution to the community! You will be remembered 🤗

[Skunnyk]

Thank you for you message. I think you perfectly summarize the situation of yaourt.
Speaking for myself : I do not plan to maintain yaourt anymore.
The codebase is old, in bash, have implementations issues and other aur helper have superseded it these last years.
Maybe it's time for yaourt to retire to the attic ? Maybe @larchunix have another opinion :)
If someone is willing to revive it and want to contribute, we can give access to the project.

[f2404]

Hey @Skunnyk, have you personally switched to another helper? which one?
I'm still using yaourt.

[Skunnyk]

I'm still using yaourt from time to time, and pikaur lastly. I don't have extended aur needs :)

[AladW]

If someone is willing to revive it and want to contribute, we can give access to the project.

@eli-schwartz

[eli-schwartz]

Rewriting yaourt is something I've thought about doing for a couple years, but have (obviously) never gotten around to.

FWIW: I've got the usual numerous objections against current code implementations of yaourt, but the underlying featureset and objectives has always been something I liked, a lot.

Nothing has ever replaced pacdiffviewer for me. And I'm actually very fond of package-query as a command-line tool and will not infrequently use it on its own just to pull formatted RPC information from the AUR. :D

[actionless]

@Skunnyk are there any yaourt features you are missing in pikaur?

[AladW]

Considering both yaourt and pikaur are very apt at breaking things, I'd say that's unlikely.

[ghost]

I noticed the PKGBUILD for yaourt still has @Skunnyk @larchunix and archlinuxfr on it as maintainers.

If the software is indeed unmaintained and still contains the security issues related to sourcing PKGBUILDs before showing them then perhaps it should be removed as to not give the illusion that there is support or that all things are fine.

Myself I switched from yaourt to yay as soon as I became aware of this months ago.

[actionless]

@AladW let me explain why i was laughing from your statement (because there were people who were blaming me in taking fun from you without a reason):

considering what there are only two ways to proof an application to be correct: via unit test coverage or via mathematical proofing of all algorithms

among aur helpers only pikaur have a measured test coverage and only one aur helper is written in haskell (so math analysis could be used however i'm not aware if it's the case there)

so your attempts to paint pikaur in black colors just because you personally dislike me is plain funny

[ghost]

@actionless come on, what the hell? Don't bring your issues with Alad from other unrelated discussions here!

@Skunnyk can you please archive the repo in repo settings and add "Unmaintained" word in repo description?

[eli-schwartz]

considering what there are only two ways to proof an application to be correct: via unit test coverage or via mathematical proofing of all algorithms

Mathematical proofs, yes. Test suites, no.

among aur helpers only pikaur have a measured test coverage and only one aur helper is written in haskell (so math analysis could be used however i'm not aware if it's the case there)

At least aurman, aura, and yay also have unittests. But anyone who claims their test suite has perfect coverage can be mathematically proven to be a liar.

[actionless]

@svitoz but that's a reply on her message here, originally when i saw it i left only a laughing emoji. but as you can see i wasn't even talking to her first, she herself was looking for the conflict.
so that's a mystery for me why you all ignoring what she not the first time personally attacking me first and start complain on me when i'm trying to defend myself from her. Or you assume what she needs some special care or extra protection?

@eli-schwartz i wasn't saying anything about "perfect coverage" (idk from where it coming on your side), i was talking about "measured coverage"

just having the tests is nice, but without measured coverage there is no reliable way to determine which parts of the application are actually covered by those tests, which not, which skipped

if you are trying to be a maximalist -- you could say what mathematical proof also don't mean anything because it could be a mistake or incompleteness in a confirmation model

but point is what saying what some app is "always break" is not so smart for someone who don't have any objectively measurable qualities/statistics (or while such qualities or statistics are saying the opposite) and basing the opinion only on the personal bias to its developer

tl;dr "show me aur helper / pacman wrapper which breaks less often than pikaur and proof what it's true"

[pklapperich]

I keep yaourt around for yaourt -C. It's still the most intuitive tool I've found for managing *.pacnew files. Maybe pulling that out into a standalone tool would be worthwhile.

[Skunnyk]

Hi,

After some conversations, we have decided to archive the yaourt github project.
Once archived, the project will be read only, so I let it open a few days to finish the discussion here, for example if someone want to forks and revive the project :)

Maybe pacdiffviewer ( https://github.com/archlinuxfr/yaourt/blob/master/src/pacdiffviewer.sh.in ) is a part someone wants to improve (I haven't looked for alternatives, maybe something already exists :)).

I'll update the README too soon.

Thank you everyone for your contributions !

[Morganamilo]

Maybe pacdiffviewer ( https://github.com/archlinuxfr/yaourt/blob/master/src/pacdiffviewer.sh.in ) is a part someone wants to improve (I haven't looked for alternatives, maybe something already exists :)).

There's pacdiff from pacman-contrib. I'm sure they'd welcome contributions.

[Skunnyk]

Haha, true, and I even already used pacdiff… shame on me :)

[f2404]

Thanks @Skunnyk, it's been fun!

Just to clarify: archiving yaourt won't affect package-query, I will continue keeping eye on it.

[eli-schwartz]

pacdiffviewer is a lot more complex, and thus more useful, than the existing pacdiff program. In general, the idea behind this has not really been beaten... I still routinely use it.

The only other comparable tool I've seen is https://github.com/foutrelis/pacmarge which uses an online database of all config files in the archlinux.org official repos and does not handle custom packages, thirdparty repos, or derivative distros.