When will you stop breaking backwards compatibility?

[sarmong]

I have a few pacsripts of my own and I want them to work without any shenanigans. However each time I need to install something (or, god forbid, reinstall the system), I have to spend hours trying to fix my pacscripts.

If I lock the old version - your pacscripts don't work. If I upgrade - mine don't. This has happened so many times that it is annoying.

I understand you want to improve the software, but please make it so that old scripts work as well. Maybe add a pacscript-ver field or something. (if you do, please don't break the scripts that don't have it). And arch pkgbuild format seems time-proven, I don't understand why not just take it and call it a day.

[oklopfer]

I have a few pacsripts of my own and I want them to work without any shenanigans. However each time I need to install something (or, god forbid, reinstall the system), I have to spend hours trying to fix my pacscripts.

You can also just ask us for help, either here or in the Discord. The refactors are always small, there is no need for you to spend hours on them.

If I lock the old version - your pacscripts don't work. If I upgrade - mine don't. This has happened so many times that it is annoying.

We always post release announcements explaining any changes, and any updates that pacscript maintainers may need to make to their packages.

I understand you want to improve the software, but please make it so that old scripts work as well. Maybe add a pacscript-ver field or something. (if you do, please don't break the scripts that don't have it). And arch pkgbuild format seems time-proven, I don't understand why not just take it and call it a day.

The PKGBUILD format is exactly what we aim to reflect, and have slowly over the years moved closer towards it. But:

1. the project is actively maintained by about 3 people, and all of us are students
2. Each time we have moved closer to it, we have had to introduce some breaking changes, to refactor to a more standard format
3. Pacstall does not build packages for Arch, it builds .deb packages. This means we have to find proper mediations between the PKGBUILD and deb formats, and sometimes that means creating our own unique features to handle these cases. We also always keep our wiki up-to-date whenever we release.

[Elsie19]

Can you provide a list of breaking changes you found frustrating?

[Elsie19]

Also would it be useful to have pre-release announcements relating to breaking changes?

[sarmong]

@Elsie19 , so I looked through the git history of my repo and here's what I found. I cannot vouch that all of them were breaking changes, but most definitely were.

I switched from Arch to Debian exactly for the reason of stability, but with each upgrade of pacstall I am afraid that something will break.
I really appreciate you guys making this software as this is exactly what Debian-based systems lack. However, it is really painful to use with all these breaking changes.

1. install() -> package(), postinst() -> post_install()
2. description -> pkgdesc, version -> pkgver
3. depends stopped accepting string ("pkg1 pkg2") and changed to array (("pkg1" "pkg2")) (Not sure about that)
4. prepare() { true } ; build() { true } were required and then not. (Don't remember if this was backwards compatible or it was erroring)
5. url -> source, name -> pkgname, hash -> sha256sum, ${STOWDIR} -> ${STAGEDIR}
6. prepare(), build() and package() started to require cd "${_archive}"
7. sudo stopped working, had to remove it from scripts.
8. ${STAGEDIR}/${pkgname} -> ${pkgdir}
9. Previously, the packages worked without .SRCINFO, now they don't
10. When replaces is not specified, -I started failing to replace old version of the package (not sure why it happened on my packages, I think not all upstream packages have it. And I mean replaces="${pkgname}", not some -git or other)
11. My repo stopped working without distrolist
12. cd "${_archive}" not working. As I can see, in some I removed it, in some changed to cd "${gives}", in some - cd "${gives}-${pkgver}"`. Don't remember why.
13. Packages worked without specifying arch=, now they don't
14. Autoreconf error for rofi-calc pacstall-programs#6149
15. Many packages in the main repo are now check for os and cannot be installed on Debian anymore, which is a shame. Iirc, I tried some packaged and just removed the line that was checking distro and it worked.

[sarmong]

Also would it be useful to have pre-release announcements relating to breaking changes?

In any case, I can push changes only after the new version is released. IMHO, the best way is to deprecate, but not remove the public API in the next release, and remove in the release after. I.e. something works in v6, deprecate, but keep it working in v7, and remove in v8 (if there is too much overhead keeping it. If not (like it's just a naming thing) - I guess it can be kept for longer)

The PKGBUILD format is exactly what we aim to reflect, and have slowly over the years moved closer towards it.

But why not adopt it immediately as a public API, even if not internal functionality is implemented, and implement it step by step?

This means we have to find proper mediations between the PKGBUILD and deb formats, and sometimes that means creating our own unique features to handle these cases.

I thought that there isn't much difference in terms of the variables and functions of package scripts. I mean, the insides of functions will be different. But package, post_install and other stuff seems to be universal.

We also always keep our wiki up-to-date whenever we release.

I just checked and couldn't find any mention that arch is now required.

[Elsie19]

I made a wiki page for how to maintain a custom repo: https://github.com/pacstall/pacstall/wiki/Maintaining-a-Custom-Repo

[Elsie19]

I will go through each one and try to explain our reasoning if that helps it seem less like we've been making arbitrary decisions.

1. install() -> package(), postinst() -> post_install()

The install() -> package() was a two-fold issue:

1. The first was that the install function clashes with the very popular install program that I'm sure you've seen and used before.
2. We were looking to bring higher compatibility between PKGBUILDs and pacscripts, so we looked at the PKGBUILD spec and changed it to package() for that reason.

For postinst() -> post_install(), the second reason above applies here.

2. description -> pkgdesc, version -> pkgver

The both were done for PKGBUILD compatibility, and the second was done because at that point, we had version (a string) and pkgver() (a function), where version was the canonical version, and pkgver() was for getting a git packages downloaded hash. It was not the clearest, so we combined them, and eventually removed the function entirely.

3. depends stopped accepting string ("pkg1 pkg2") and changed to array (("pkg1" "pkg2")) (Not sure about that)

This was an objectively good change, I don't think I need to justify this. Lists in bash should be arrays, not strings.

4. prepare() { true } ; build() { true } were required and then not. (Don't remember if this was backwards compatible or it was erroring)

This was also a good change. Before that, even bin packages would have to have two useless functions there.

5. url -> source, name -> pkgname, hash -> sha256sum, ${STOWDIR} -> ${STAGEDIR}

url -> source was for PKGBUILD compatibility, and also url could only ever support one URL.

name -> pkgname was for PKGBUILD compatibility.

hash -> sha256sum was also for PKGBUILD compatibility, and it opened up the use of more than just SHA256, as you can use more than just that now.

6. prepare(), build() and package() started to require cd "${_archive}"

They were never required to have that line. We put that there as a stop-gap to try to seamlessly move from pre-5.0.0 to 5.0.0. You can read the release notes and I'm sure you'll see that this was not intended to be a permanent "feature".

7. sudo stopped working, had to remove it from scripts.

We transitioned to using bwrap in 5.0.0, and with that, removed the need for running sudo in a potentially untrusted environment on the host system.

8. ${STAGEDIR}/${pkgname} -> ${pkgdir}

You can still use that. We just won't accept that in our repo.

9. Previously, the packages worked without .SRCINFO, now they don't

Fair, but we use that to make our repository completely parsable for any useful information without having to source and extract variables/arrays from bash scripts.

10. When replaces is not specified, -I started to failing to replace old version of the package (not sure why it happened on my packages, I think not all upstream packages have it. And I mean replaces="${pkgname}", not some -git or other)

replaces="${pkgname}" would make the package try to replace itself, which it's already doing. That behavior seems odd but what's more odd is putting that line there.

11. My repo stopped working without distrolist

If you pull workflows from upstream, this shouldn't be an issue.

12. cd "${_archive}" not working. As I can see, in some I removed it, in some changed to cd "${gives}", in some - cd "${gives}-${pkgver}". Don't remember why.

Yes, we removed it, because we released 5.0.0 on May 1st, 2024, which was plenty of time to update scripts (242 days actually). The new behavior functions like PKGBUILDs, where you must cd into the extracted directory, which you can determine by downloading it manually and checking.

13. Packages worked without specifying arch=, now they don't

PKGBUILD compatibility.

14. Autoreconf error for rofi-calc pacstall-programs#6149

In this case, it seems that autoreconf is built differently between Ubuntu and Debian, so the incompatible must be put in there.

15. Many packages in the main repo are now check for os and cannot be installed on Debian anymore, which is a shame. Iirc, I tried some packaged and just removed the line that was checking distro and it worked.

Can you give a list of those packages? We realized that wholesale blocking distros is generally not a good idea, so we added version constraints, which covers 90% of the reasons why certain packages don't build on Debian but do on Ubuntu. We have a section on our wiki about that.

---

I think that repo maintainers should absolutely be checking https://github.com/pacstall/pacstall/commits/develop/ for breaking changes, which are marked with something like feat(bla)!: message. We have been aggressively keeping our repo up to date with breaking changes and have given many methods on how to do that, such as:

1. https://pacstall.github.io/pacstall-news/2024/04/28/prepping-extern-repos.html
2. pacstall/pacstall-programs@c8422db
3. pacstall/pacstall-programs@8412ed1
4. ref(*): deprecate presumptive _archive pacstall-programs#6702
5. refactor(*): convert to arrays pacstall-programs#3129

[sarmong]

I am not saying these weren't the good changes. This is about the way the are handled. For regular software you can break backwards compatibility immediately with a new version. Because the user can choose to stay on the old one until they are ready to migrate. With pacstall, the user chooses to either be able to install their packages with the old version, or upstream packages with the new version.

Can you give a list of those packages?

https://github.com/search?q=repo%3Apacstall%2Fpacstall-programs+%2Fincompatible%5C%3D.*debian%2F&type=code

[Elsie19]

I meant the list of packages where removing incompatible works on the distros that are listed in it.

[sarmong]

One is librewolf-deb, not sure about others