Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)

2020-09-30 Thread Ludwig Nussel
zypper calls the rpm command. So a new transaction for each package..

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-701263564___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)

2020-09-30 Thread Ludwig Nussel
s/zypper/zypp/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-701263659___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)

2020-09-29 Thread Ludwig Nussel
zypp installs rpms individually and disables transaction scripts:
https://bugzilla.suse.com/show_bug.cgi?id=1041742

If a script knew why it was called it could probably decide to ignore the 
"useless" calls. Like eg by passing more arguments. Legacy scripts would not 
use them and continue to function.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-700574842___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)

2020-09-23 Thread Ludwig Nussel
Trying to implement file triggers for mandoc to register and unregister man 
pages in the whatis database I ran into some strange behavior. Note I can't use 
transfiletrigger as zypp doesn't support that :(

- triggers are executed several times on upgrade and uninstall for the same 
package (ie the package with the trigger itself)
- the argument is always zero. So the triggers cannot handle upgrades 
differently.
- the triggers do not know the package a file belongs to. In case of mandoc 
installation that would be helpful as it could then just rebuild the database 
to speed things up instead of calling it on single files. Similar on erase it 
would just do nothing and wait for rpm to remove the database later.

```
tw:/root # rpm -q rpm
rpm-4.15.1-7.2.x86_64
tw:/root # cat filetriggers.spec
Name:   filetriggers
Version:1.0
Release:%{?rel}%{!?rel:1}
%define nvr %{name}-%{version}-%{release}
Summary:Testing file triggers
Group:  testing
License:GPL
BuildArch:  noarch

%description
%{summary}

%install
install -D -m 644 /dev/null %buildroot/usr/lib/foo/1
install -D -m 644 /dev/null %buildroot/usr/lib/foo/2

%filetriggerin -- /usr/lib/foo
echo "filetriggerin %{nvr}: $@"
cat > /dev/null

%filetriggerun -- /usr/lib/foo
echo "filetriggerun %{nvr}: $@"
cat > /dev/null

%preun
echo "preun %{nvr}: $@"

%files
/usr/lib/foo
/usr/lib/foo/1
/usr/lib/foo/2
tw:/root # for i in 1 2; do rpmbuild -bb filetriggers.spec --define "%rel $i"; 
done
[...]
tw:/root # cd /usr/src/packages/RPMS/noarch/
tw:/usr/src/packages/RPMS/noarch # rpm -U filetriggers-1.0-1.noarch.rpm 
filetriggerin filetriggers-1.0-1: 0
tw:/usr/src/packages/RPMS/noarch # rpm -U filetriggers-1.0-2.noarch.rpm 
filetriggerin filetriggers-1.0-1: 0
filetriggerin filetriggers-1.0-2: 0
filetriggerin filetriggers-1.0-2: 0
filetriggerun filetriggers-1.0-1: 0
preun filetriggers-1.0-1: 1
tw:/usr/src/packages/RPMS/noarch # rpm -e filetriggers
filetriggerun filetriggers-1.0-2: 0
filetriggerun filetriggers-1.0-2: 0
preun filetriggers-1.0-2: 0
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] config file moving aid (#1296)

2020-06-30 Thread Ludwig Nussel
There are efforts to get rid of distro default config files in /etc in favor of 
built in defaults or files in eg /usr/etc. Means rpms no longer install stuff 
into /etc. The transition there however requires some handling of existing 
files in /etc. Unmodified ones should get removed while modified ones need to 
stay in place. Right now on openSUSE side we have an advice in the wiki to add 
[scriptlets](https://en.opensuse.org/openSUSE:Packaging_UsrEtc#Moving_of_configuration_files)
 in %pre and %posttrans. Not exactly convenient nor smart.

Also, that model assumes that such packages have no mention of the config files 
in /etc at all anymore. IMHO it would still be desirable own the ones in /etc 
though. So if one runs `rpm -qc vim` one would see `/etc/vimrc` even if that 
file isn't shipped.

So assuming the old package had

%config(noreplace) /etc/vimrc
The new one should have something like

%config(missingok) /etc/vimrc
or

%ghost %config /etc/vimrc

Currently however the first version would lead to actually installing a 
(potentially zero sized) file in /etc, and the %ghost form would not remove an 
unmodified config on update.

Any thoughts on this?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1296___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RPM Translation subpackage(s) (#1276)

2020-06-22 Thread Ludwig Nussel
> How do you detect a binary that will want to load some specific translations? 
> Is it just some guess or should be up to packager to fill in or?

FWIW in openSUSE many packages have a "-lang" subpackage to contain all 
translations. Those packages in turn have automated provides that translate 
into a locale namespace for libsolv, eg. `rpm -q --provides bash-lang`:
```[...]
locale(bash:es)
```

That basically instructs libsolv to install `bash-lang` if `bash` is installed 
and the system is in Spanish.
https://github.com/openSUSE/rpm-config-SUSE/blob/master/fileattrs/locale.attr
https://github.com/openSUSE/rpm-config-SUSE/blob/master/scripts/locale.prov

That mechanism would still work if splitting would be fine grained to the level 
of one locale per package.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1276#issuecomment-647512303___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] rpmdb --exportdb needs write access to the lock file (#1266)

2020-06-10 Thread Ludwig Nussel
rpmdb --exportdb calls rpmtxnBegin() with RPMTXN_READ flags. Internally that 
function calls rpmlockNew() and rpmlockAcquire(). Neither function has a flags 
parameter to specify what kind of lock is requested. rpmlockNew() automatically 
creates a read lock if it can't open the .rpm.lock file in RW mode. 
rpmlockAcquire() however wants to establish a write lock always so won't work 
on a  read-only lock.

So in the end it means that means rpmdb --exportdb only works as root on a 
read-write file system. Doesn't work for unprivileged users, nor on read only 
file systems. That doesn't seem to be intentional given the rpmlockNew() 
fallback to a read lock.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1266___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

2020-04-06 Thread Ludwig Nussel
that's a good start at least. There's also --importdb. So with slightly more 
code that could sync back and forth with a directory

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151#issuecomment-609752886___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

2020-04-06 Thread Ludwig Nussel
Note that installing the headers on disk as part of package installation does 
not exclude actually using one of the existing database formats.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151#issuecomment-609743345___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

2020-04-06 Thread Ludwig Nussel
> * People can and will randomly manipulate files to force the package 
> manager to do weird things (it's even documented in various troubleshooting 
> guides)

Well, obfuscating the database for the purpose of avoiding people to mess with 
it doesn't sound like an overly good motivation. RPM headers would still be 
binary and are signed, so you can't arbitrarily edit them like text files 
anyways.
 
> * It is not possible to atomically update package information, nor 
> provide any transactional qualities. This means also it's possible to have 
> races all over the place, depending on filesystem and OS semantics.

I have no insight to the other database formats so can't comment on how that is 
handled. For setups that never modify the running system but rather either 
prepare images or modify snapshots the transactional capabilities of rpm do not 
matter anyways. If anything goes wrong, no new snapshot/image gets produced.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151#issuecomment-609733671___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

2020-03-31 Thread Ludwig Nussel
With uncompressed payload one could even copy the full rpm into 
/usr/lib/sysimage/rpm/installed and reflink the data.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151#issuecomment-606700263___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] RFE: rpm without database (#1151)

2020-03-31 Thread Ludwig Nussel
How about not storing rpm headers in some binary database anymore but rather as 
individual files on disk?

Ie rather than stuffing them into /usr/lib/sysimage/rpm/Packages.$format just 
dump them as is, eg
/usr/lib/sysimage/rpm/installed/hello-1.2-3.x86_64.rpm

That opens several possibilities

- The database format does not matter anymore. The "database" could be moved 
back to /var as it would be  just a cache of indices that can be thrown away 
any time. rpm could just re-create them if needed or asked to.
- A diff of the file system tree of different versions of the operating system 
(eg snapper snapshots) would show right away what  packages changed.
- Similarly it would make life easier for container layers as  there's no 
binary database blob involved.
- One does not actually need rpm for simple introspection. `ls` is  sufficient 
for the equivalent of `rpm -qa`. In fact given simple  packages, basic rpm 
operations could be emulated in shell even.
- rpms could "package" their header as %ghost. So the header would actually be 
part of the file system representation of the package.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1151___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RFE: integrate user/group handling into rpm (#1032)

2020-03-18 Thread Ludwig Nussel
Maybe a provides generator could be used that parses sysusers files to avoid 
any extra tags the packager has to put in spec files. Then a new kind of 
trigger that acts on such provides could create the actual user.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1032#issuecomment-600645936___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint