[packager@rpm-builder etc]$ env | grep PATH
PATH=/home/packager/.local/bin:/home/packager/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I guess /user/local/bin or /usr/local/sbin is our first choice? Do we need
--enable-pedantic-posix for /usr/local/bin or /usr/local/sbin?
Two options:
1. Move the conflicted files: cd, umask and wait to /usr/sbin, while keep the
others in /bin directory.
2. Install all of them to /usr/sbin directory.
Which one is better?
Wang qi.
> On Apr 2, 2024, at 06:25, Laurent Bercot wrote:
>
> If the default PATH has /usr/sbin before
Hi all,
Laurent has suggested i ask on IRC about this, but since (a) i'm
in UTC+10, (b) i'm constantly moving between a few different
networks, and (c) my bouncer is currently out of action (it's a
Story), i thought i'd ask on these lists instead, to facilitate
asynchronous replies. :-)
And yes, since execline-provided cd, umask and wait, when called via a
PATH search (not that a shell will ever do that, but execvp() can), will
substitute themselves to Fedora-provided POSIX binaries, it is necessary
to build execline with --enable-pedantic-posix in order to prevent
trouble
Got that, thanks.
> On Apr 2, 2024, at 06:32, Laurent Bercot wrote:
>
> And yes, since execline-provided cd, umask and wait, when called via a
> PATH search (not that a shell will ever do that, but execvp() can), will
> substitute themselves to Fedora-provided POSIX binaries, it is necessary
>
After check the installed package of execline on alpine. I choose to install
main part of execline to /usr/bin.
Create /usr/sbin directory, create relative symbol link for cd, umask and wait
to /usr/bin/execline.
# rebuild the conflicted files (filesystem, bash package) in /usr/sbin
mkdir -p
Sure.
> On Apr 2, 2024, at 06:25, Laurent Bercot wrote:
>
> No, /usr/local is reserved, as the name implies, for local installations:
> packaged software cannot use it.
>
> If the default PATH has /usr/sbin before /usr/bin for all users, then the
> best thing is probably to install cd, umask
Yes, skalibs, execline are different projects. The GitHub site is just a
central and temporary place to hold the spec files.
For skalibs project, I build 4 rpm packages: skalibs, skalibs-devel,
skalibs-devel-static, skalibs-doc.
skalibs-devel depends on skalibs. Just follow the aports
On Mon, Apr 01, 2024 at 07:26:22PM +0800, qi wang wrote:
> Could you provide some suggestion? Or does anyone has some experience
> on that?
In my (admittedly ugly) package, I simply delete execline's `cd' and
`umask'; `wait' is renamed to `execline-wait', just like `execline-cd'
and
file /usr/bin from install of execline-2.9.4.0-1.fc39.x86_64 conflicts
with file from package filesystem-3.18-6.fc39.x86_64
file /usr/bin/cd from install of execline-2.9.4.0-1.fc39.x86_64
conflicts with file from package bash-5.2.26-1.fc39.x86_64
file /usr/bin/umask from
Today, execline rpm package is ready now.
The following is the directory of rpmbuild.
[packager@rpm-builder rpmbuild]$ tree
.
├── BUILD
├── BUILDROOT
├── RPMS
│ └── x86_64
│ ├── execline-2.9.4.0-1.fc39.x86_64.rpm
│ ├── execline-devel-2.9.4.0-1.fc39.x86_64.rpm
│
On Mon, Apr 01, 2024 at 12:46:27PM +, Laurent Bercot wrote:
> This means that your execline package cannot run execline scripts that
> use cd, umask or wait. It may work for you, but it is not suitable as a
> general audience package.
Certainly. I avoid RedHat-like systems except when
On Mon, Apr 01, 2024 at 09:09:52AM +, Laurent Bercot wrote:
> I haven't looked in detail, but I'm not sure why you want everything
> in one single RPM.
The packages he makes are not monolithic; the package by me, noted in
earlier messages, is monolithic, due to historical reasons and a lack
Laurent:
It seems that execline will install files to /bin. On fedora, it will conflict
with other packages:
[packager@rpm-builder rpmbuild]$ sudo rpm -ivh
~/rpmbuild/RPMS/x86_64/execline-2.9.4.0-1.fc39.x86_64.rpm
Verifying... # [100%]
In my (admittedly ugly) package, I simply delete execline's `cd' and
`umask'; `wait' is renamed to `execline-wait', just like `execline-cd'
and `execline-umask' (which are not conflicting and so not deleted).
This means that your execline package cannot run execline scripts that
use cd, umask
Yes, skalibs, execline are different projects. The GitHub site is just a
central and temporary place to hold the spec files.
For skalibs project, I build 4 rpm packages: skalibs, skalibs-devel,
skalibs-devel-static, skalibs-doc.
skalibs-devel depends on skalibs. Just follow the aports
Luckily, Fedora provides the following default PATH for us. Where the first two
directories is provided by packager user’s .bashrc. Other path are provided by
/etc/profile (system default).
[packager@rpm-builder etc]$ env | grep PATH
I haven't looked in detail, but I'm not sure why you want everything
in one single RPM.
skalibs, utmps, execline and s6 are different projects. A package
should
be one project, not a set of projects. A package manager will handle
dependencies between packages and install all the rpms that
18 matches
Mail list logo
