Pre-devlog notes

I did the math recently. I only have enough actual time left in this challenge to get one project done and have time to get it reviewed and rated, and that’s only if I’m lucky.

So I decided that the “My first slack bot”, “Untitled”, and “Arch on your Android” projects are canceled and my other projects will be paused for a few months or more so that I can dedicate the rest of my coding time to easyAPT, which is almost done. Just 3 hours, a demo system, and a Github release left, and the project I’m most proud of will be ready for anyone to use.

Also, I won’t be making a .deb file, and won’t be trying to get it on the Debian or Ubuntu repositories. That would be cool, but that process can take a lot of time. Maybe later, though, but definitely not now.

There’s an even simpler way to install it without even cloning the repo once Github releases are published: just download one of the files there (like the .7z, the standard .zip, etc), make the easyAPT directory in the folder you want to, and other steps that I’ll mention in the Github page because they might change.

I still will have to do research on how I can create a light Debian environment with the easyAPT demo - a limited version of easyAPT that I’m planning to create later. But that’s for later…

Also: an announcement: easyAPT is done!
cue ‘tada’ fanfare
This is the one of the last devlogs I will be posting for it, for this first version anyway. And I can finally make a Github release!

Also this devlog might not be too detailed because there’s still a lot of things I have to do to ship my project.

Devlog 8

Besides a full bug testing of every option, here are the new features:
1. A progress bar on the startup prompt
Just a nice inclusion. It zooms by within 5 seconds.

2. New updater tool
It’s still experimental, but I scraped the old code and started over. It’s a lot more stable, but still has a small chance to delete the wrong thing.

3. Github features finished
In fact, all the main menu options are finished.

Sorry about the limited detail, I have a lot to do. Thanks for reading anyway, and if you have a question, comment, or suggestion, type it down below.

Pre-devlog notes

Sometimes when I’m coding I think it’s only been 5 minutes and then I check the time and I realize It’s been 3 hours…

Also after chasing my own tail for hours trying to troubleshoot and code Arch on your Android, I decided it was a good idea to go back to my first project, which has a bunch of new features now and has no dialog flag mistakes.

easyAPT devlog 6, maybe 7

A ton of new features have been added to easyAPT.

1. .easyaptgithub.sh

This adds an option in the menu to check if Github is working properly on your system. Plus, some options will run it anyway to check if everything is working.

2. Issue/bug reporting

You can now use easyAPT to report issues with it, right there in the menu.

3. About easyAPT

There is a new About easyAPT option in the menu. Just some basic stuff about the version. Plus, it has missing info that I can’t fill in until I do more research, make a Github release, and ship my project.

There’s a ton more, but I don’t have time to discuss it all in a devlog.

Thanks for reading! If you have any questions, comments, or suggestions, please leave them down below!

Pre-devlog notes

Yes, this is how I do my devlogs now. I want to take advantage of all Stardance’s new devlog features to make them a bit neater.

Also, this may be my first time I made a commit to easyAPT’s Github repository in, like, 2 weeks. I just decided to take a break from coding for a little bit.

Actual Devlog 6

We went from I forgot the other version and the GitHub commit history has missing info for some reason to JUN30-V32.

What changed?

I have changed a good amount of things with easyAPT, including…

• The version system instead of organizing them by what versions were released on what day, I organize them by the date that they were released and the overall version (eg, JUN9-R7 to JUN9-V20). V, in my case, means revision number.)
• The updating tool 90% bug fixed
• Case $? in errors I made this mistake a lot. In case statements, which I use a ton of, you have to use case “$VARIABLE” in or case “TEXT” in, not case $? in, or it’ll always assume the last option. Take this sample code as an example,

#correct
case "$?" in
            0)
                    echo "Success"
            *) 
                    echo "Failure"
esac
#This code displays the right end result for a command. But my mistake was
case $? in 
           0)
                   echo "Success"
            *)
                   echo "Failure"
esac
#Which always assumes it fails, every time, even if $?=0.

Thanks to Vim (the super useful editor that’s my new favorite), what would’ve taken hours took a split second.

How close am I to my first GitHub release of easyAPT?

Pretty close now. All the options menu work fine. When I paste the final contents into easyAPTmenu.sh, then this project will be pretty much finished and ready for anyone to demo. But, there’s still a bunch of bugs I need to fix.

What’s next for easyAPT?

There’s a lot of planning for what’s up next.

• Case statement bug fixes I turned on a Vim feature that highlights some lines red if there are syntax errors. For some reason I haven’t figured out yet, most, if not all, of the ;;s and the esacs in my script are highlighted red. I haven’t experience bash stop the script due to syntax errors, so I’m going to have to look through the code and maybe do research.
• About menu option Takes a few seconds to code. Just a nice little inclusion telling the user who made it, the current version, and possible licensing info (if we get to that stage)
• More bug fixes I’ll test every single possible option before pasting the menu part into another script.
• Making ./easyAPTmenu.sh hidden I’d like to turn easyAPTmenu.sh into .easyAPTmenu.sh. It may seem like a small change, but adding a dot to the beginning hides the file by default, like if you typed “ls”. This is the case for the version files as well as others used for Github and Wakatime.
• Anything else Things will get added and removed from here as releases go.

Thank you for reading! If you have any questions, comments, or recommendations, please let me know!

Devlog 5

All the menu options have been ready, but the updating tool is really, really buggy. I will fix that later. The next step in easyAPT’s process is to do debugging.

I moved from JUN4-R7 to JUN8-R4.

I plan to test all the options in the menu, including all submenus, and all checks (by failing them). That means that there will be several more sub versions before the first actual Github release.

Devlog 4

There was some syntax error on line 622 I didn’t know about when I was working on this, but besides that I got a lot done with easyAPT and the development phase is almost done.

I moved from JUN4-R3 to JUN5-R7.

The 2 main changes:
One: All menu options except tool updating have been finished but not bug tested - that’s later!

Two: The version string no longer includes the year. That was redundant.

Devlog 3

Small changes have been made from JUN3-R6 to JUN4-R3. I was able to get the remove options done and bugs fixed in the “List installed packages” option (not all of them are fixed though).

I am planning to lock the .rpm to .Deb conversion utilities to experimental versions of this. Their version string is “JUN4-2026-R5-EXP” instead of “JUN4-2026-R5”, for example. This is because the alien utility I am using for it ends by dropping the user in a shell prompt (sh to be exact), which hangs the exit script, and if you run it within the sh shell and try the conversion again, it ends up being a APT, sh, and easyAPT instance and confliction mess that slows down your system and, in the worse case, is hard to regain control of.

I made a sample ./easyAPTmenu.sh that redirects to the ./easyAPT.sh. This is because I was tired of typing :!./ and the up key in the Vim editor EVERY SINGLE TIME I selected an option in the menu and the operation finished. I didn’t do this before because that’s 2 seconds of checks it makes that I have to wait for instead of instantly with the planned ACTUAL easyAPTmenu.sh file, which is coming soon.

This should take a few more days to finish up, and then I can finally make my README.md and my first Github release of easyAPT!

PS: nothing has changed with the menu, I just needed a graphic for the devlog and wanted to see how the menu would change over devlogs.

Things have happened with easyAPT. I went from version JUN2-2026-R6 (June 2, 2026 Revision 6) to JUN3-2026-R5 (June 3, 2026, Revision 5). Here’s what’s new in JUN3 (R5), known bugs, and what’s planned next.

One: An updating tool has been added to the menu powered fully by Github. It hasn’t been implemented yet, but it should test if .version in the repo matches the .version on placed on the device, and if it doesn’t (after user confirmation), it will move the .update.sh to the home directory and run it, which will remove all contents of the easyAPT directory, reclone the whole directory back onto the device, run “chmod +x *” (or chmod +x .) so all the scripts are executable, and remove itself from the home directory.

Two: The first 4 options may have bugs (I haven’t tested them fully yet), but I think they are ready for use. I know for sure that the last option works fine (obviously), but I want to add a line of code to it first.

Three: I can reuse the code from previous options into new ones, so some will get done way faster.

Four: All options when done, instead of going back to the menu, quit with a “No such file or directory” error. This is because it links to a nonexistent “easyAPTmenu.sh” file that I can’t make until the first script (easyAPT2.sh) is fully finished and bug checked.

I haven’t made an actual Github release yet or a README.md (these scripts simply aren’t ready yet), but I plan to soon.

I’m working on a Linux shell script for a terminal-based interface for managing packages. This is especially useful for people who are first timers to Linux and don’t know what “sudo apt update” is.

I’ve got the menu done, but not any of its actions. I am planning to add the version number as part of the startup text.