All kinds of files dumped into etc that do not belong there

[starquake]

I installed thelounge archlinux package and it dumps all its files there. I use etckeeper to backup my changes to etc but now it also backups log files. Which is not supposed to happen.

Can the files that aren't config files please be moved to another location? I can make a pull request if you want.

EDIT:
Let's make a checklist:

• Update PKGBUILD to install into /var/lib
• Create post-install message to move logs, sqlite and any other files to new location
• Test this upgrade in a VM
• Update documentation

[brunnre8]

No, thelounge likes to keep it the same across distros so that support is easier (my initial PR had it, it was rejected)

[maxpoulin64]

One thing you could do for yourself is to symlink those directories to somewhere in /var so that etckeeper doesn't pick it up. It's not optimal, but it should work.

I fully expect this issue to get reopened once in a while because we're definitely in the wrong with regards to the FSH here, and Arch users tends to like things to be proper 😛 Hopefully that decision can be reevaluated at some point. That is technically also applicable to other distros as well, /etc is just not where log files belong. It worked when all we had was the users, but that has clearly evolved into a general data directory and that belongs to /var/lib.

[brunnre8]

agreed, now go and convince xpaw, off you go

[starquake]

I still would love to install thelounge without having the log files in etc. So how about we fork this repo and make our own PKGBUILD? Maybe even submit it as an alternate version to AUR.

[brunnre8]

feel free to change the pkgbuild however you want.
However submitting to the AUR is a poor idea, duplicates are not allowed and I will file a deletion request if you do as this is against the aur guidelines.

Why don't you tell etckeeper to ignore the files? I'm sure they have something like a gitignore file no?

[starquake]

I could change my etckeeper config. But I do think only config files belong in /etc. Not any other files. It seems we disagree on that. Which is fine!

I do feel however that there are more people that disagree, so that's why I would want to share my alternate installation. Instead of keeping it to myself.

Before submitting to AUR I will check if it complies with the rules. The reason I think there might be a possibility this is okay is because of the second part of this rule:

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

I hope you also allow my alternate (but common) package installation configuration. So please don't file a deletion request.

BTW. I'm kinda sad that the first thing you think of is filing a deletion request.

(I edited this comment right after publishing because I wasn't finished yet but I hit CTRL-ENTER or something that published my comment too soon)

[brunnre8]

But I do think only config files belong in /etc. Not any other files. It seems we disagree on that. Which is fine!

We don't actually, I agree. However upstream doesn't and I can see their point (ease of support).
We should just patch TL to make than a config option imo.

having extra features enabled and/or patches in comparison to the official ones.

This is patches to the upstream source, not differences in packaging (minus compile time features)

[brunnre8]

why don't you file an issue against the actual TL code, explaining your issue? Or hop in the irc channel during the times when xpaw is active.

He's the one to convince, not us.
Unless forced I won't break with what setup he wants to have for the distro packages.

[starquake]

We don't actually, I agree.

With "we" I meant upstream and me. I thought upstream could be used as a term to describe the team that decides what happens in the code.

This is patches to the upstream source, not differences in packaging (minus compile time features)

I know the exact situation does not apply here. I only quoted it as a reason why I think they might allow it. As I said, I would discuss it before submitting to AUR so let's just wait to see what happens if and when I submit it.

I was planning to come up with a solution that doesn't involve changing any TL code. I was looking for a fix in the PKGBUILD. That's why I filed an issue here.

Instead of discussing this or convincing someone, I'd rather put some effort in coming up with a solution and then hop in the channel and say: Hey look at this! I made a thing and now the AUR package complies with the package guidelines

[brunnre8]

It does comply with the pkg guidelines as is 😉 "should" being the operative term here (rfc speak)

as for how this would be solved and some discussion here: #9 (commits)
Check out my revert

[brunnre8]

Oh and btw, re

I hope you also allow my alternate (but common) package installation configuration. So please don't file a deletion request.

BTW. I'm kinda sad that the first thing you think of is filing a deletion request.

Why? That's just upholding the AUR guidelines and policies, no offense intended but there should be exactly 2 packages for TL, binary and -git

[starquake]

Yeah, don't really want to discuss guidelines and interpretation of them.

In my opinion: There should be exactly 2 packages for TL and /etc should be used for config files only. And that's what I'm trying to accomplish here.

I would rather not have log files in my /etc directory on my system.

I'll take your commits into account while looking for a solution.

[starquake]

So... this is what I was talking about:
master...starquake:move-to-var

This is what changed

• Switched to using the source archive available on github
• Rename downloaded file to thelounge-v4.1.0.tar.gz
• Switched to yarn to build the package (like in the documentation)
• I moved the "patching" of .lounge_home to prepare
• Used ${pkgname} everywhere consistently
• Removed a bugfix for npm that wasn't used anymore
• Moved TL homedir to /var/lib/thelounge to more closely follow the package guidelines
• Move config files to /etc and symlink them back to /var/lib/thelounge

So now only config is in /etc and nothing else. There is however 1 issue. When you upgrade there will be some old files still there. If you are interested I can try to fix that out too.

This all was inspired by the AUR PKGBUILD files for thelounge and thelounge-git

[brunnre8]

The issue isn't technical, I know how to do it (I linked you to the PR where I suggested more or less exactly what you do now).

It was rejected by the lead maintainer of TL on the reasons mentioned in said PR.

Unless we have approval from him I don't see us changing to your setup I'm afraid.

[brunnre8]

@xPaw mind chiming in?.
Do you see a way forward here that would be ok with you? In principle it would also be nice for the other distro packages if we would more closely follow the filesystem hierarchy.

If you remember I had a similar notion when I first took over the packaging and the point with /etc being the wrong location for logs is valid.

Would that better be done in the TL source? And then use the usual means of finding the state dir? For user units it could be put wherever the xdg spec stores it's state files.

What do you think?

[starquake]

I was perfectly aware of the fact that it wasn't a technical issue. That's exactly the reason I went ahead and fixed it. And I shared my solution for others to see and use.

I prefer an /etc directory without sqlite files over a /var/lib that does not have symlinks.

I just can't accept having sqlite databases in my /etc directory.

I'll have a conversation with the AUR forums and see what they think. Maybe they can convince me otherwise.

[xPaw]

@starquake's patches sound fine, but you will need to take care for existing installations to handle upgrades.

Perhaps we should do the same in the debian repo to match. But upgrades and documentation will need to be handled.

[starquake]

So does this mean this issue can be reopened and we can start working towards a solution?

As you already saw I'm willing to help.

[starquake]

I see there is the option of a post-install script. I'll do some testing and see if I can move the old files there.

[brunnre8]

take care not to rely on post install scripts though... users may skip package updates and or downgrade and upgrade willy nilly as they please...

Better is probably to just print a warning, the symlink should be transparent anyhow to TL

[xPaw]

Symlink yes, but you shouldn't break existing installations.

[starquake]

It doesn't break existing installations. But the old log files will be in /etc/thelounge/logs but TL expects them in /var/lib/thelounge/logs now so the old logs won't be loaded.

[maxpoulin64]

The convention in Arch is usually to have the post-install script for a few versions (until a major release?) until it's reasonable to assume everyone has been upgraded at some point. Although it's also not uncommon to just warn the user to do the changes manually, for example: MariaDB and postgresql both require the user to manually take care of upgrading the database structure.

Arch generally doesn't babysit its users. You're expected to read the output of pacman while installing and address any messages that gets printed there.

[xPaw]

Arch generally doesn't babysit its users.

That's a lame excuse for making the life miserable :) The script is likely pretty easy to achieve - if /etc/thelounge exists, and /var/lib/thelounge doesn't, move it over.

But the old log files will be in /etc/thelounge/logs but TL expects them in /var/lib/thelounge/logs now so the old logs won't be loaded.

It will also reset the config/users, no?

[starquake]

That's a lame excuse for making the life miserable :)

It's The Arch Way. They generally think getting babysat(?) is miserable. :-) But a move should be doable.

It will also reset the config/users, no?

No it won't. As far as the package manager is concerned. The config files were in /etc/thelounge/thelounge.conf and /etc/thelounge/users/*.conf and they still are.

EDIT: Well I say that but I'm not entirely sure about /etc/thelounge/users/*.conf. Anyway I'm planning to test this scenario in a VM.

[starquake]

I created a checklist at the top. I added updating the documentation but I think that's actually out of the scope for this issue. Also the documentation mentions ${THELOUNGE_HOME} so I'm not sure if the documentation even needs changing.

Can someone else pick this up? Or at least point me in the right direction?

[starquake]

I found the repository for the documentation. I'll see if anything needs changing.

[eli-schwartz]

I still would love to install thelounge without having the log files in etc. So how about we fork this repo and make our own PKGBUILD? Maybe even submit it as an alternate version to AUR.

As mentioned, duplicate packages which merely change where the config files go don't really meet the rules for duplicates. Speaking with my Trusted User hat on, I would definitely accept the deletion request -- or submit my own deletion request and accept that, if I noticed it myself while looking through the AUR.

I would instead recommend submitting an orphan request in such cases, if you have an improvement to suggest which the current maintainer is not willing to be convinced to implement. A TU will then evaluate it and try to decide if it's a sufficient issue to warrant transfer to a new maintainer.

Fortunately it seems the question will not come up anyway. :)

[eli-schwartz]

That's a lame excuse for making the life miserable :) The script is likely pretty easy to achieve - if /etc/thelounge exists, and /var/lib/thelounge doesn't, move it over.

If it is possible to automatically make upgrades work properly, Arch Linux doesn't say "no babysitting, do it by hand". The problem is it is rarely as easy as all that. Users are expected to pay attention in order to resolve things which cannot be done automatically, or which are ambiguous.

Would moving it automatically work when thelounge is currently running? How should users handle that case?

[starquake]

@eli-schwartz Thanks for educating me. Good to know there are options in place for cases like you describe.

Just to be clear: I never intended to do all that. I was just looking for ways to move the binary files out of /etc and share that version with as many people as possible. That's why it was written as a question and using the word "Maybe".

I will try to make the upgrades work automatically. I will be testing the upgrade in a VM just to make sure everything works while running or any other pitfalls I might overlook.

[brunnre8]

I'd rather just emit a warning, Eli has a point

Would moving it automatically work when thelounge is currently running? How should users handle that case?

The answer is it doesn't handle it.

[eli-schwartz]

(That was me trying to gently imply that Arch avoids doing things for the user out of pragmatism, not pedantry. But hey, if you can figure out a pragmatic way to make it actually work and which never does the wrong thing, then by all means feel free to do it. Your call.)

[starquake]

Thanks for contributing to the conversation! I will take all this into account!

[starquake]

Just a heads up. I did not have hardware to start working on the issue. But I do have it now! So I can start working on this now.

[starquake]

You can close this if you want. I slowly stopped using The Lounge/IRC. I still think it's a cool product though.

Sorry!