Hello,
I'd like to propose adding /usr/libexec to the openSUSE FHS and
reverting the definition of %_libexecdir in rpm back to /usr/libexec
so that libexec content is installed there.
Currently, openSUSE overrides rpm to define %_libexecdir as /usr/lib,
which leads to pollution of the /usr/lib directory with executable
content as well as 64-bit content when there shouldn't be any. The
/usr/libexec has been in use on RH/Fedora and Mageia systems in the
Linux world, but has its origins in BSD and is still used today in
BSDs and variants (like Mac OS X). The usage of /usr/libexec for
libexec content has also been recognized by FHS with v3.0, released in
2015. In the Linux distribution landscape (that is, all major
families, not just RPM ones), /usr/libexec is in use on Red Hat,
Mandrake, Gentoo, and Slackware families.
This is a breaking change, as it means that as packages are rebuilt,
libexec content *should* migrate from /usr/lib to /usr/libexec. The
major advantage of migrating the libexec content is that it will make
openSUSE consistent with other major RPM-based Linux distributions,
and ease efforts in supporting SUSE distributions along with Red Hat
ones by removing the need for hacks and tweaks to support two
different hierarchies. This simplifies the portability headaches in
supporting both distribution families, and makes it easier for
applications that were originally aimed for RHEL/CentOS to run on
SLE/openSUSE Leap.
This change would be done in three stages:
1. Make the change to the filesystem package to add /usr/libexec to
the hierarchy.
2. Add /usr/libexec to allowed prefixes in rpmlint-checks and remove
spec-cleaner rule that assumes /usr/lib == %_libexecdir.
3. Make the change to the rpm package to set %_libexecdir back to
/usr/libexec. This one will cause a fair bit of work to fix packages
that do the wrong thing one way or another with %_libexecdir.
What do you all think?
Best regards,
Neal
--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I apologise if this is not the right place to ask, but I cannot seem to
find the package
kernel-default-debuginfo-4.12.14-lp150.12.70.1.x86_64
Both debug repositories
(http://download.opensuse.org/debug/distribution/leap/15.0/repo/oss/ and
http://download.opensuse.org/debug/update/leap/15.0/oss/) are active
have been refreshed
I've tried installing
kernel-default-debuginfo-4.12.14-lp150.12.67.1.x86_64
and searching for updates, but to no avail.
Google returns a single Japanese page (ftp.riken.go.jp), but the file
itself isn't available on the page.
What am I missing?
Thanks,
Felix
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
The scanning tools in the hplip package need "python3-scikit-image" for
full functionality. That dependency is currently missing, and I'm
considering adding it. I can't test this well myself because I'm
missing suitable hardware. But the way hplip typically deals with
missing dependencies at runtime, users will at best see a generic or
misleading error message; more likely, some options will simply be
missing or greyed out for no obvious reason.
My problem is that "python3-scikit-image" pulls in a whole bunch of
additional python packages (155 packages / 576 MiB on my TW system,
which already had quite a bit of python stuff installed). Installing it
with --no-recommends pulls in "only" 8 packages / 156 MiB.
I'm now wondering if I should add this requirement to hplip as
"Requires" or "Recommends". I wouldn't normally classify it as a hard
requirement, as it's only needed for special functionality provided
only with special HP ScanJet models (e.g. "punchhole removal"). From
that point of view, it's clearly a "recommends" or even a "suggests".
However, if I use "recommends", people using "--no-recommends" won't
get the scikit stuff at all and miss functionality in obscure ways,
whereas people using "--recommends" would get the full 155 recommended
packages. If I use "Requires", OTOH, the result with "--recommends"
would be the same, but with "--no-recommends", users would "only" need
to install the 8 packages that python3-scikit-image pulls in hard, and
most likely the required run-time functionality would be available to
them. The latter would be my personal preference as a user (well - for
my printer model the extra functionality isn't offered anyway, so for
me personally, using "suggests" is actually the best).
Another option would be to separate out these new scanning tools "hp-
scan" and "hp-uiscan" into an extra package and add the requirements
there. I don't think they have many users yet, as I expect most users
to simply use the usual SANE tools, xsane and scanimage. But that's
just a guess. But if I do this, I have the same problem, because
"hplip" would need to have a "Recommends: hplip-hpscan".
Hints and opinions welcome.
Martin
In the discussion about a non-rpm controlled /etc I missed the migration path for files changed by the admin. Is there a proposal about how a disappeared '%config /path' or '%config(noreplace) /path' is supposed to be handled? If not, here is my idea how it could be done.
There are plenty of "empty" files which are marked as "%config". In case of local modifications to such files, they will be kept as '/path.rpmsave' when '/path' is not packaged anymore. It will be cumbersome for the admin to move all of '/path.rpmsave' back to '/path' once '/path' is not under rpm control. Two rpm macros are needed to automate the restore of '/path' from '/path.rpmsave'. In the %pre section '/path' and '/path.rpmsave' will be tracked, in the %posttrans section '/path.rpmsave' will be moved back to '/path' under the following condtions:
1: '/path' exists and was unmodified: rpm will silently remove '/path'. Action: No action required.
2: '/path' exists and was modified: rpm will preserve a copy of '/path' as '/path.rpmsave'. Action: %posttrans will rename '/path.rpmsave' to '/path'
3: '/path' exists and was unmodified, '/path.rpmsave' exist, both are identical : rpm will silently remove '/path'. Action: remove stale '/path.rpmsave'
4: '/path' exists and was unmodified, '/path.rpmsave' exist, both differ : rpm will silently remove '/path'. Action: remove stale '/path.rpmsave'
5: '/path' exists and was modified, '/path.rpmsave' exist, both are identical : rpm will preserve a copy of '/path' as '/path.rpmsave'. Action: %posttrans will rename '/path.rpmsave' to '/path'
6: '/path' exists and was modified, '/path.rpmsave' exist, both differ : rpm will preserve a copy of '/path' as '/path.rpmsave'. Action: %posttrans will rename '/path.rpmsave' to '/path'
7: '/path.rpmsave' exists: rpm does nothing with '/path.rpmsave'. Action: remove stale '/path.rpmsave'
I think with this logic most of the tedious work of renaming will be avoided, with no obvious risk. In my testing '%config /path' and '%config(noreplace) /path' behave identical once '/path' changes from rpm controlled to non-rpm controlled, there will be always a '/path.rpmsave' for local modifications.
The logic below is supposed to address all 7 cases above, it just a proof-of-concept at this point. The usage of basename is wrong, it is not ready for build-compare.
Here is a short excerpt from the long list of "empty" config files which will benefit from such helper macros:
/etc/default/grub
/etc/exports
/etc/grub.d/*
/etc/libguestfs-tools.conf
/etc/systemd/*.conf
/etc/xen/*.conf
Olaf
Name: config_noreplace
Version: %(date -u +%%Y%%m%%d%%H%%M)
Release: %(date -u +%%S)
Summary: %{name}
License: GPL
Group: Example
BuildRoot: %{_tmppath}/%{name}-%{version}-build
# 0 or 1
%define carry_config_paths 0
%define path1 %{_datadir}/%{name}/conf.txt
%define path2 %{_datadir}/%{name}/keep.txt
%description
%prep
%setup -q -c -T
%build
%install
pushd %{buildroot}
mkdir -p %{buildroot}%{_datadir}/%{name}
%if %{carry_config_paths}
cat > .%{path1} <<_EOT_
# Example: preserve a copy of local changes
_EOT_
cat > .%{path2} <<_EOT_
# Example: always keep the local changes
_EOT_
%endif
%pre
echo "pre %{name} %{version}-%{release} $# $0 $*"
trackdir=%{_tmppath}/%{name}-%{version}-%{release}
pre_preserve_config() {
local _path="$1"
local pre_config=$trackdir/$(basename ${_path}).pre.md5
local pre_rpmsave=$trackdir/$(basename ${_path}).rpmsave.pre.md5
if test -f "${_path}"
then
md5sum < "${_path}" > $pre_config
fi
if test -f "${_path}.rpmsave"
then
md5sum < "${_path}.rpmsave" > $pre_rpmsave
fi
}
if mkdir "$trackdir"
then
pre_preserve_config %{path1}
pre_preserve_config %{path2}
fi
%post
echo "post %{name} %{version}-%{release} $# $0 $*"
%preun
echo "preun %{name} %{version}-%{release} $# $0 $*"
%postun
echo "postun %{name} %{version}-%{release} $# $0 $*"
%posttrans
echo "posttrans %{name} %{version}-%{release} $# $0 $*"
trackdir=%{_tmppath}/%{name}-%{version}-%{release}
posttrans_perserve_config() {
local _path="$1"
local pre_config=$trackdir/$(basename ${_path}).pre.md5
local pre_rpmsave=$trackdir/$(basename ${_path}).rpmsave.pre.md5
local post_rpmsave=$trackdir/$(basename ${_path}).rpmsave.post.md5
if test -f "${_path}.rpmsave"
then
md5sum < "${_path}.rpmsave" > $post_rpmsave
fi
# config was present, now no config.rpmsave
# -> no admin changes, nothing to do
# config was present, now config.rpmsave
# -> admin changes, move config.rpmsave to config
# config and config.rpmsave was present, now config.rpmsave
# pre:
# -> if config == config.rpmsave then remove config.rpmsave
# -> if config != config.rpmsave then preserve both
# post:
# -> if config == config.rpmsave, move config.rpmsave to config
# -> if config != config.rpmsave
if test -f "$pre_config" && test -f "$pre_rpmsave"
then
# pre: config and config.rpmsave was present
if cmp -s "$pre_config" "$pre_rpmsave"
then
: pre: config and config.rpmsave identical, modification status unclear
if test -f "$post_rpmsave"
then
: post: admin changes, restore config
mv -v "${_path}.rpmsave" "${_path}"
else
: post: no admin changes, remove stale config.rpmsave, rpm removed config
rm -v "${_path}.rpmsave"
fi
else
: pre: config and config.rpmsave differ, modification status unclear
if test -f "$post_rpmsave"
then
if cmp -s "$pre_config" "$post_rpmsave"
then
: post: admin changes, restore config
mv -v "${_path}.rpmsave" "${_path}"
else
: post: no admin changes, remove stale config.rpmsave
rm -v "${_path}.rpmsave"
fi
fi
fi
elif test -f "$pre_config" && test ! -f "$pre_rpmsave"
then
: pre: config present + config.rpmsave absent, modification status unclear
if test -f "$post_rpmsave"
then
: post: admin changes, restore config
mv -v "${_path}.rpmsave" "${_path}"
fi
fi
: cleanup
rm -f $pre_config
rm -f $pre_rpmsave
rm -f $post_rpmsave
}
posttrans_perserve_config %{path1}
posttrans_perserve_config %{path2}
rmdir $trackdir
%files
%defattr(-,root,root,-)
%dir %{_datadir}/%{name}
%if %{carry_config_paths}
%config %{path1}
%config(noreplace) %{path2}
%endif
Hi,
I moved the /etc/cron.* packages from the filesystem to the cron
package.
Why?
1. On MicroOS we don't have cron, but the existing directories
did confuse people who where wondering, why their cron scripts
where never executed
2. The permissions macros couldn't be used in the filesystem package
due to dependency order problems, so this could be fixed now.
3. There are only 20 packages left from over 12360 source packages,
so you cannot count cron an integral/required part of the OS anymore.
All packages containing cron files are adjusted to this change, you
only need to accept my SRs.
And there is no change for users, it's a pure packaging change.
Maybe the package maintainers of this remaining package could even
convert this remaining cron files to systemd-timers ;)
apt-cacher-ng
atop
cacti
cronie-anacron
froxlor
leafnode
logdigest
logwatch
matomo
munin
nagios
openlmi-providers (openlmi-pcp)
patch2mail
rkhunter
sarg
storeBackup
texlive-filesystem
tmpwatch
yast2-ntp-client
yum
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi list,
I would like to propose a change in our packaging guidelines,
specifically the part about bundling static libraries in a
*-devel-static subpackage (see:
https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static
lib in a subpackages, we put it in the "main" package instead and add a:
Provides: bundled(foo) = $version
into the spec file?
The full guidelines are here:
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libra…
This has the advantage that we don't have this additional -static
package, which is relatively pointless beside keeping track of bundled
libraries. Querying the bundled packages can be then done as follows:
rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper:
zypper search --provides 'bundled(*)'
Any opinions/thoughts?
Cheers,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
On Tue, Jul 23, 2019 at 7:33 AM Richard Brown <rbrown(a)suse.de> wrote:
>
> On Mon, 2019-07-22 at 15:28 +0200, Thorsten Kukuk wrote:
> > On Mon, Jul 22, Neal Gompa wrote:
> >
> > > This change would be done in three stages:
> > >
> > > 1. Make the change to the filesystem package to add /usr/libexec to
> > > the hierarchy.
> > > 2. Add /usr/libexec to allowed prefixes in rpmlint-checks and
> > > remove
> > > spec-cleaner rule that assumes /usr/lib == %_libexecdir.
> > > 3. Make the change to the rpm package to set %_libexecdir back to
> > > /usr/libexec. This one will cause a fair bit of work to fix
> > > packages
> > > that do the wrong thing one way or another with %_libexecdir.
> > >
> > > What do you all think?
> >
> > I don't see really a problem with this subdirectories in /usr/lib,
> > as this is nothing a normal user should care about, and for
> > packages, RPM does take care of if the package uses the correct
> > macros. But I would not vote against it, too.
> >
> > I have a much bigger problem with all the configuration files in
> > /usr/lib and subdirectories, because this makes it really hard
> > and difficult for admins to find the right one.
>
> While I agree with Thorsten's additional problem, I don't think the
> existance of that issue negates Neal's points.
>
> I would quite like to see /usr/libexec established in openSUSE..but how
> we will handle executables that currently live in /usr/lib for the 32-
> bit version and /usr/lib64 for the 64-bit version?
>
The last time this had been brought up, it sounded like those were
packaging mistakes, and that binaries being installed into /usr/lib64
needed to be fixed anyway. I don't know how many of those are like
that (I don't have an easy way to get all the spec files and grep
through them like I do for Fedora package specs...), but I think those
would just be fixed so that binaries would be installed correctly into
/usr/libexec.
I don't know of a circumstance where we need multiarch *binaries*
along with multiarch *libraries*.
--
真実はいつも一つ!/ Always, there's only one truth!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello all,
For use in libreoffice, chromium and others I've created macro that
should allow you to limit jobs based on some constraints you can set
later on in the spec to avoid OOM crashes.
The usage is pretty straight forward (Once it is accepted in
Tumbleweed):
===
BuildRequires: memory-constraints
%build
# require 2GB mem per thread
%limit_build -m 2000
make %{?_smp_mflags}
====
Here the _smp_mflags vaule for 8GB machine would be 4 while default is
number of cores (lets say 16)...
Both macros %jobs and %_smp_mflags are overriden as such the
integration should be really painless if you need to do something like
this.
Tom
Hi,
I think for the /usr/etc move of distribution provided configuration
files, we should introduce a RPM variable.
Any suggestions for a name?
My suggestions would be:
%_distro_sysconfdir
%_usr_sysconfdir
%_usretc
Any other ideas?
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org