Include deployment script

[Carlosmape]

To avoid package-manager dependency, it could be a good idea to have an installation/deployment script to deploy repository in to the system.

This method could avoig tasks to generate all distros packages, reducing releases complexity and adding compatibility for non-debian distros (I use Manjaro BTW)

More over, developers will have an easy way to "test in production" before make any pullrequest (I want to collaborate Slimbook as developer BTW)

Regards! :smile:

[slimbook]

Well, that's a great idea! How would you like to implement it? Maybe we should create a folder called development, there are some translation scripts that could also be moved there.

[Carlosmape]

Yeah I think if it is in the root folder it whould be easier to execute, but it can be placed whatever you want. My idea is something like this:

1. Check for dependencies (if there is some missing dependency, output it to allow user manually install needed packages)
2. Deploy in the system
3. Run translations scripts over installed package (not in repository folder to avoid translation changes in it)

[slimbook]

Yes, I agree with the location. The third point is also interesting, I think we could use some arg to change translations in the repository folder once they have been tested and no args to run translations scripts over installed package.

[Carlosmape]

I am trying to generate this script but IDK what is exacty the process. I search in my system old slimbook installation and tried to replace same files:

• Resources under /usr/share/slimbookbattery (content seems to be repository src/ content and a folder /bin)
• Binaries under /usr/bin (I created soft links to /usr/shared/slimbookbattery/bin/* ones)

But when I tried to run them i get the next error: $ slimbookbattery python3: can't open file '/usr/share/slimbookbattery/bin/../src/slimbookbatterypreferences.py': [Errno 2] No such file or directory Did the directory structure changed from older version?

[slimbook]

All content in /bin is moved to /usr/bin in the system, This is (currently) the content of debian/install (shows where files go):

bin/* /usr/bin/
debian/changelog /usr/share/slimbookbattery/
slimbookbattery.desktop /usr/share/applications/
src/* /usr/share/slimbookbattery/src/
bin/* /usr/share/slimbookbattery/bin/
images/* /usr/share/slimbookbattery/images/
images/slimbookbattery.png /usr/share/pixmaps/
custom/* /usr/share/slimbookbattery/custom/
default/* /usr/share/slimbookbattery/default/
policykit/* /usr/share/polkit-1/actions/
src/tranlations/* /usr/share/slimbookbattery/tranlations/
debian/changelog /usr/share/slimbookbattery/src/
LICENSE /usr/share/slimbookbattery/
udev-rules/* /etc/udev/rules.d

[Carlosmape]

Ok thanks!

But I think the trouble wont fix, couse /usr/bin/slimbookbattery will keep trying to look ../src/slimbookbatterypreferences.py isn`t it?

Anyway I will try it later :+1:

[slimbook]

There is not any change, does the file exist? ''' /usr/share/slimbookbattery/bin/../src/slimbookbatterypreferences.py'' works for me

[slimbook]

Yes, your route is correct, if you run /usr/bin/slimbookbattery should show the same error doesn't it?

[Carlosmape]

So... let's see if I am properly understanding: It's needed to place src/slimbookbatterypreferences.py in /usr/src (in other words, /usr/share/slimbookbattery/bin/../src/slimbookbatterypreferences.py')

I think the error is in the relative path, (and obviouly something that I am not undestanding :sweat_smile: )

[slimbook]

We are not using the route /usr/src, I think you are looking for /usr/share/slimbookbattery/src/slimbookbatterypreferences.py which shows the main window. The file in /usr/bin just acts as a 'launcher' :smile:

[Carlosmape]

src/* /usr/share/slimbookbattery/src/

I think here is the trouble, in my (very) older slimbookbattery version, this path does not exists.... src/* /usr/share/slimbookbattery/src/ Its simply all inside /usr/shate/slimbookbattery

[ehooo]

@Carlosmape it was my fault i don't think in /usr/bin location only on /usr/share/ folder, but on the debian/install the frist line copy the bin in that location.

[slimbook]

Well there has been a big change between that version and the current one, I thought you meant 4.0.0 or 4.0.1(:laughing:), we should work with the latest install. Maybe we should also remove the /bin folder inside the program folder to avoid confusion.

[slimbook]

@ehooo why would it be your fault?

[ehooo]

@slimbook is bin app is called from /usr/bin the related path will not be worked. Maybe is possible create a simlink to shared bin folder

[Carlosmape]

yep I tried to make a simlink but it does not work (cause of the rel path) It would be a good idea to remove as you say. The trouble is that rel paht allowed us to run directly from repository, isn't it?

[Carlosmape]

@ehooo Do you mean to deploy entire repo in /usr/share and then create a simlink in usr/bin/ pointing to repo's bin folder?

[Carlosmape]

I created a draft pull-request (WIP) to see the progress...

I now can run slimbookbattery by making the simlink in /usr/bin/ pointing to /usr/share/slimbookbattery/bin/ folder, but I can't store configuration:

I imagine that I have not performed the deployment correctly (IDK the rules to follow, sorry for my inexperience)

[slimbook]

@ehooo Oh, that's true, I though i fixed that before (commit), that's why I was a bit lost :smile: PD: Which code editor are you using?

[slimbook]

@Carlosmape It's okey you just have to run the check_config.py (postinstallation script), which is in the program folder /src

[Carlosmape]

Done! I added.

I still deploying entire repo in /usr/share/slimbookbattery but now I am able to launch it properly :)

[ehooo]

@Carlosmape yes I mean create:

$ sudo ln -s /usr/share/slimbookbattery/bin/slimbookbattery /usr/bin/
$ ls -las /usr/bin/slimbookbattery 
0 lrwxrwxrwx 1 root root 19 oct 18 17:00 /usr/bin/slimbookbattery -> /usr/share/slimbookbattery/bin/slimbookbattery

@slimbook I'm use pycharm

[slimbook]

We have to check dependences referenced here (in arch names are different), also there are some imports which are files from the app, like utils

[Carlosmape]

I already check Python dependencies in this commit f9f08fab237e2391d320efb3496fe6f56900e9ce The idea is to parse all imports and check if theyre installed using pip3. If they're not installed, then script tries to install.

System packages are harder to check without using a package manager. I tried using whereis command but as you say, package names could change and I do not see a properly way to do it taking debian/control as template

I'll think about it and maybe check the distro to know what package manager should the script uses to check dependencies

[slimbook]

Yes, it's difficult, we will figure it out, but for testing is cool, Thanks!!

[SwampRabbit]

Going to throw my 2 cents in here as a Distro maintainer and packager. The preferred (best) way is to let the Distros ensure installation is done correctly, they know how to address the python and system dependency packages, package names, file installation location issues, etc, etc. Distro package-managers that you are trying to avoid make life simpler and faster, if installation scripts were the way to go, package-managers wouldn't exist in the first place.

Downloading and installing things outside of Distro repositories to handle dependencies or other things is not safe or proper from a stability or security standpoint. In Debian it is not allowed. I mentioned this in the issue started for slimbookintelcontroller.

When applications start randomly pulling things in from pip or other places, putting executables all over the place, you can cause instability across a whole OS. Then the Distro itself may users complaining to them directly. Distros will test an application and dependencies and verify its all good, application developers can't all do that.

If you want a Distro agnostic install option use Flatpak or AppImage. Not Snap as it doesn't work on all Distros/OSes.

I'm sharing an excellent article by Drew Devault (dev/maintainer for Alpine Linux, Wayland, tons of other things), it is a great article in general, but really speaks for app developer understanding very well:

There are a few things you can do to make this work better. • Ship your software as a simple tarball. Don’t ship pre-built binaries and definitely don’t ship a “curl | bash” command. Naive users will mess up their systems when they use them. • Use widely adopted, standard build systems and methodologies. Use the standard approach for your programming language. They have already been through the gamut of distros and their operating modes are well-understood by packagers. • Ship good release notes. Distro packagers read them! Give them a head’s up about any important changes which might affect their distro. • Be picky with your dependencies and try to avoid making huge dependency trees. Bonus: this leads to better security and maintainability! • Maintain a friendly dialogue with distro maintainers if and when they come asking questions. They’re the expert on their distro, but you’re the expert on your software, and sometimes you will meet to compare notes.

https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

One approach is to have a separate branch with just packaging items, so debian folder, .spec file, pkgbuild file, that sort of stuff. If package maintainers need to make corrections they can do it there or submit PRs to the main branch. Keeps your source code repo clean, reduces complexity in your source code, and addresses lots of other issues.

[SwampRabbit]

oh and another option if you want to have a way to distribute applications to as many GNU/Linux distros as possible, the best option is the OpenSUSE Build Service (OBS)

https://openbuildservice.org/ https://build.opensuse.org/

While its created by OpenSUSE it can be used to create repositories and packages for Debian, Arch, OpenSUSE, RedHat, Fedora, Ubuntu, Raspbian, Magia, etc, etc.

[slimbook]

Wow, OpenSUSE Build Service is so interesting, thanks! So you are saying that we should separate src (which would be in the main branch) from debian folder (with just package building files) and there could be a developer's branch (which would contain all, to make testing easier).

Ship good release notes.

This should also be improved.

PD: If you have an example repository, we would love to see it.

[SwampRabbit]

So how you set up and manage your repos, is really up to you, but separating out "packaging" items from the main branch has the benefit of your source tarball not including Debian, RedHat, or Arch, Flatpak, Snap, AppImage packaging files, and so on. For example, sometimes if I am packaging something that all all those extra files that we don't need then I download the tarball, delete those files, annotate that I deleted them, then build the package. A RedHat/Fedora package doesn't need the Debian files as much as I don't need the .spec file.

One way to do it: main - primary stable source development - currently working branch distro_packaging - branch includes debian folder, .spec file, pkgbuild file, etc, etc

Some developers make branches for each version of the application, 4.0.3, 4.0.4, etc. You don't have to have a separate branch for distro packaging, its up to you.

This is an example of a branch I made for an application I packaged not too long ago, you can see it is separate from the main branch https://github.com/SwampRabbit/pamixer/tree/debian_packaging

The Lutris application is a decent example of not having distro packaging branch, but lots of working/development branches. https://github.com/lutris/lutris

Here are some examples of OBS repos: https://build.opensuse.org/repositories/home:strycore https://software.opensuse.org/download.html?project=home%3Astrycore&package=lutris https://build.opensuse.org/repositories/hardware:razer https://software.opensuse.org/download.html?project=hardware%3Arazer&package=polychromatic https://software.opensuse.org/download.html?project=home%3Ajstaf&package=onedriver

[slimbook]

thank you!

[Carlosmape]

Very interesting @SwampRabbit I will take a look OFC. @slimbook What should we do with the script?

[slimbook]

We will keep it in de developing branch, it's very useful to test in different distros locally without uploading to the repository. I still have to structure the repository btw, but first I have to look through all the information that @SwampRabbit provided us :)

[slimbook]

@SwampRabbit this is our first approach to the opensuse build tool SlimbookBattery, hope you can tell us how can we make the 'download package' link work for testing, or some advice (I've seen you have some repos there) :)

[SwampRabbit]

@slimbook very nice and you had a bunch of builds complete too!

Not sure why nothing is showing up under "Download package" button. You have it set to "Publish" and it seems to be populating repos fine https://download.opensuse.org/repositories/home:/Slimbook/Debian_11/

I'm far from an expert with OBS, only use it for stubborn packages, or testing different builds. MX Linux does all our own packaging and into our own Repo. But our Packaging Lead knows OBS very very well, I can ask him to take a look at your setup if he has time.

One thing I did notice is that you made the package at the Top level "Home Project", I typically use "Sub-Projects". I don't know if this is better or worse, but it helps me keep things organized. I can't remember if I read somewhere you have to have a Package inside a Project, but if the package was at the Home Project level then it wouldn't work like you want. Here is a example of one I did quickly recently to test something. https://build.opensuse.org/package/show/home:SwampRabbit:webmin-test/webmin

You can "link" dependency packages in Projects across into other Projects, just something to remember cause it helps a lot sometimes.

I remember that a long time ago, I watched videos here https://openbuildservice.org/help/ The two at the very bottom look like they might be most useful.

[slimbook]

Thank you, I'm going to try passing it to a subproject, maybe it fixes something,

But our Packaging Lead knows OBS very very well, I can ask him to take a look at your setup if he has time.

Thank you, that would be very much appreciated :)

I remember that a long time ago, I watched videos here https://openbuildservice.org/help/

Yes! still have to watch those, I got stuck in the download package one, but I'll watch them.

If I try checking out the package (osc -A https://api.opensuse.org checkout home:Slimbook:SlimbookBattery/SlimbookBattery && cd $_) I get this error:

• 'home:Slimbook:SlimbookBattery/SlimbookBattery' is already an initialized osc working copy

[SwampRabbit]

hmmm... I've actually never used OSC, I do everything through the web interface.

I messaged our packaging lead, it'll probably be a day or two until I get a response or he posts in here.

I'm looking at packaging intel-undervolt, should be interesting trying to get it to work with systemd, openrc, and elogind

[SwampRabbit]

The MX Packaging Lead replied to me with

Probably it's because the package name that they give it doesn't exactly match any package name that the build produces. That's the most common cause of that problem...

But it looks like you got it working already!

https://software.opensuse.org//download.html?project=home%3ASlimbook%3ASlimbookBattery&package=slimbookbattery

[slimbook]

Yes, I made it but I didn't realise how,

Probably it's because the package name that they give it doesn't exactly match any package name that the build produces. That's the most common cause of that problem...

Might have been that, thanks for helping! I think I'm moving this issue to a discussion to talk about packaging