Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

several minor problems #8

Open
pmattern opened this issue Mar 15, 2015 · 5 comments
Open

several minor problems #8

pmattern opened this issue Mar 15, 2015 · 5 comments

Comments

@pmattern
Copy link

This issue is meant to summarize a couple of problems which should be improved, imo, but which don't justify a bug report on their own.
All findings made with recent AUR package aarchup.

icons
The build procedure creates archlogo.svg but skips archlogo.png. If this is intentional (which I don't believe), aarchupstartup.example should be modified as it's referencing archlogo.png.
I think archlogo.{png,svg} should be placed in /usr/share/icons/hicolor/{32x32,scalable}/apps. This would be according to the Icon Theme Specification and hence make the icons available to other applications as well.

systemd
According to systemd documentation, see e. g. Section "Unit Load Path" in man (5) systemd.unit unit files provided by packages should go to /usr/lib/systemd/system. Folder /etc/systemd/system is for local configuration adjustments only, e. g. by copying units from /usr or by using those snippets in subfolders .service.d. So aarchup.{service,timer} should be moved accordingly.
As a side effect line backup in PKGBUILD wouldn't have to cover aarchup.timer any longer.
Regarding systemd.timer I think 15min is a bit much. Normally one wants to be informed as soon as possible after booting. So I'd suggest to reduce to 5min or something.

noxaarchup, aarchupstartup.example
noxaarchup is invoking aarchup without --icon. Would be nicer to have it set, imo.
Also, I think both noxaarchup and aarchupstartup.example should set --aur by default as using this switch when cower is lacking seems to cause nothing but an error message.

messages
Given Summary starts by "New updates..." setting "Application Name" to "New Updates" doesn't seem like a good choice to me, in particular with regards to notificationd implementations which state both items in their pop-ups like the one from LXQt. Why not set 'Application Name' just to 'aarchup'?
If updates in official repos are available both old and new version are displayed, regarding AUR only the latter. This should be consistent.

@aericson
Copy link
Owner

First, thanks a lot for your input.

icons:
The .png problem should had been fixed, there has been some problems with packaging. I've fixed it now.
About the icon locations you seem to be right, I'll address it.

systemd:
I will look into moving them, but why wouldn't the backup line be needed? They are there so that when I change them in future versions, user's changes won't be overwritten (a pacnew will be created).
I also have to disagree with the 5 minutes. It's too low. In case the user is busy, to be notified every 5 minutes is just too annoying. Plus, it's easy enough to change the default.

noxaarchup, aarchupstartup.example:
I don't see a reason not to have --icon by default, I'll address it.
I don't think the --aur should be there by default, it's not semantically correct to have it set without cower being installed. Also, aarchup was always meant to be used with pacman with no aur support. This was added as an extra feature and requires an external tool. Then again, it's easy enough to change the default.

messages:
Application name should change, yes.
Long time ago, back when this was first released, pacman -Qu didn't use to show the new version of the packages. Hence there is a '+' at the end of each line. In the end it used to show something like:
curl 7.40.0-1+
I never really noticed it to be honest.

Thanks one more time :)

@pmattern
Copy link
Author

systemd
*.pacnew files get created if files provided by packages are modified. But regarding systemd the common habit is to place system-wide units in /usr and handle local configuration changes by different kinds of files that get placed in /etc additionally and hence do not belong to packages. So no need to backup systemd files in /etc.
You may have a look at packages in the official repos - they do state all kinds of configuration files in /etc in PKBUILD's "backup" line but never systemd units.
The proposal was to modify OnBootSec, not OnUnitActiveSec. Aside from this it's of course right that modifying those values locally is easy.

messages
Displaying both current and new version was introduced in pacman 4.2.0, see NEWS ("- both current and new...").
Regarding AUR it seems a bit odd to me that aarchup is displaying the new version only as cower --update is displaying both versions as well.

@aericson
Copy link
Owner

There is already a configuration file in /etc/aarchup.conf I will look into unifying all configuration to it.
I will change the OnBootSec also. Still, /etc/aarchup.conf would need to be in backup array in PKGBUILD. From docs:

For each backup file in a package being upgraded, pacman cross-compares three md5sums
...
pacman saves the new version with a .pacnew extension and leaves the modified version untouched.

For the messages, I will change it. AUR updates were only showing new version to keep output similar. But since pacman changed, no need to keep it like that. I guess I forgot to state that I was gonna change that on my previous message.

One more time, thanks for the feedback and the detailed descriptions.

@pmattern
Copy link
Author

Still, /etc/aarchup.conf would need to be in backup array in PKGBUILD.

But that's totally consistent with what I've been saying: any configuration file in /etc that's part of a package should be covered by "backup".
If /etc/aarchup.conf was delivered by the package (which doesn't apply so far) then of course it would have to be covered by "backup".
systemd is an exception in that its configuration files in /etc are normally never provided by packages but result from copying the ones from /usr, adding snippets or whatever.

@aericson
Copy link
Owner

I agree with you, that would be ideal. No idea when I will get around to do that though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants