4:02 p.m.
Hi,
For upstream projects that provide spec files in their repositories, do
y'all tend to see a common location for the spec files? Like
dist/<name>.spec or rpm/<name>.spec, etc. My organization is trying to
standardize on a location for the software we maintain, and it would be
better to use something that many in the open source community also use.
Thanks,
-Mat
4:39 p.m.
2017-10-26 15:02 GMT-06:00 Mátyás Selmeci <mselmeci.ml(a)gmail.com>:
Hi,
For upstream projects that provide spec files in their repositories, do
y'all tend to see a common location for the spec files? Like
dist/<name>.spec or rpm/<name>.spec, etc. My organization is trying to
standardize on a location for the software we maintain, and it would be
better to use something that many in the open source community also use.
Helllo I have not seem many upstream projects shiping rpm files in theirs
sources, but I have seem many with a /debian directory with all the debian
packaging stuff and some others with a /PKGBUILD dwith file used for the
Arch Linux´s AUR, since rpm is not only for Fedora I think /rpm should be a
good place to ship the rpm file.
4:46 p.m.
On Thu, Oct 26, 2017 at 5:39 PM, William Moreno
<williamjmorenor(a)fedoraproject.org> wrote:
2017-10-26 15:02 GMT-06:00 Mátyás Selmeci <mselmeci.ml(a)gmail.com>:
>
> Hi,
>
> For upstream projects that provide spec files in their repositories, do
> y'all tend to see a common location for the spec files? Like
> dist/<name>.spec or rpm/<name>.spec, etc. My organization is trying to
> standardize on a location for the software we maintain, and it would be
> better to use something that many in the open source community also use.
>
Helllo I have not seem many upstream projects shiping rpm files in theirs
sources, but I have seem many with a /debian directory with all the debian
packaging stuff and some others with a /PKGBUILD dwith file used for the
Arch Linux´s AUR, since rpm is not only for Fedora I think /rpm should be a
good place to ship the rpm file.
I've seen packaging/{debian,rpm}, packaging/, dist/, rpm/, as well as
it being a top-level file.
The projects I've worked on typically use dist/<package>.spec.
For example: https://github.com/datto/dattobd/blob/master/dist/dattobd.spec
Projects from SUSE typically use package/<package>.spec
For example: https://github.com/openSUSE/libsolv/blob/master/package/libsolv.spec.in
--
真実はいつも一つ！/ Always, there's only one truth!
4:46 p.m.
On 2017-10-26 5:39 PM, William Moreno wrote:
2017-10-26 15:02 GMT-06:00 Mátyás Selmeci <mselmeci.ml(a)gmail.com
<mailto:mselmeci.ml@gmail.com>>:
Hi,
For upstream projects that provide spec files in their
repositories, do y'all tend to see a common location for the spec
files? Like dist/<name>.spec or rpm/<name>.spec, etc. My
organization is trying to standardize on a location for the
software we maintain, and it would be better to use something that
many in the open source community also use.
Helllo I have not seem many upstream projects shiping rpm files in
theirs sources, but I have seem many with a /debian directory with
all the debian packaging stuff and some others with a /PKGBUILD dwith
file used for the Arch Linux´s AUR, since rpm is not only for Fedora
I think /rpm should be a good place to ship the rpm file.
Or
rpm/SPECS
to match where rpmbuild would look for it
--Fernando
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
5:03 p.m.
2017-10-26 15:02 GMT-06:00 Mátyás Selmeci <mselmeci.ml(a)gmail.com
For upstream projects that provide spec files in their
repositories, do y'all tend to see a common location for the spec
files? Like dist/<name>.spec or rpm/<name>.spec, etc. My
organization is trying to standardize on a location for the
software we maintain, and it would be better to use something that
many in the open source community also use.
Here are some ideas. The following projects are either strongly related
to Fedora or widely used in the project. These are just some projects I
had cloned in my personal PC for some reason, so, randomly picked:
- koji, copr-cli, FedoraReview, python-bugzilla ship spec files in the project root
directory
- pagure and mote ship spec files under the 'files/' directory
- mock ships it as 'mock/mock.spec'
- ansible ships it as 'packaging/rpm/ansible.spec'
- gofed ships it as 'hacking/gofed.spec'
- RPM does not ship a .spec file in the rpm repository (maybe somewhere
else?)
As mentioned here, Debian ships it under the debian directory in the
root dir because that's how their tooling searches for packaging data.
As pointed above, it seems that there are no default paths to ship the
spec file. Just let packagers know it exists. When packaging for
different distros, chances are the spec file will need changes anyway.
--
Athos Ribeiro
http://www.ime.usp.br/~athoscr
5:05 p.m.
From a survey of about 1700 .spec files in my current working
collection, the overwhelmingly common place to ** install **
such is in a:
%doc
directory
Most simply place them in the top directory, at a depth even
with where a V[ersioned] tarball is unpacked by the %setup
stanza. Then
rpmbuild -ta (package-V).tgz
can un-gzip and find it there and will build to order in
chained automation. I see in my local archive:
bzr/kicad/RCS/README,v:rpmbuild -ta ${PROJECT}-${YMD}.tar.gz && {
which does this. The R[elease] value gets tacked on during
the build process
This is most sensible (I have much automation for
automatic VCS CO, .spec file, and then tarballgenerators,
which substitute in various variable substitutions). See,
eg.,
ftp://ftp.owlriver.com/pub/mirror/ORC/dl/README
of which I was tracking VCS dalies and testing, before it
moved into Fedora
Others use this approaches similar to this as well -- I see
several
'%{_package}.spec.in'
files by others to that effect as well. See, eg.,
krb5-auth-dialog and GeoIP
-- Russ herrold
4:08 a.m.
If you are considering to add .spec file to your upstream project,
please be aware of this guideline:
https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_...
Vít
Dne 26.10.2017 v 23:02 Mátyás Selmeci napsal(a):
Hi,
For upstream projects that provide spec files in their repositories,
do y'all tend to see a common location for the spec files? Like
dist/<name>.spec or rpm/<name>.spec, etc. My organization is trying to
standardize on a location for the software we maintain, and it would
be better to use something that many in the open source community also
use.
Thanks,
-Mat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
10:31 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in upstream
sources
On Fri, 27 Oct 2017, Vít Ondruch wrote:
interesting to re-read
I noticed in the Scripts languages section the ** absence **
of /bin/sh (and not 'bash' with its 'bashisms'), and lua
Each should probably be present for completeness ... it may
finally provoke the lua hooks in rpm to become used, and os
useful
This may merit some discussion here before I edit the wiki
-- Russ herrold
10:54 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On 10/27/2017 05:31 PM, R P Herrold wrote:
On Fri, 27 Oct 2017, Vít Ondruch wrote:
> https://fedoraproject.org/wiki/Packaging:Guidelines
interesting to re-read
I noticed in the Scripts languages section the ** absence **
of /bin/sh (and not 'bash' with its 'bashisms'), and lua
Each should probably be present for completeness ... it may
finally provoke the lua hooks in rpm to become used, and os
useful
It's often necessary to use Lua for scriptlets which run reliably
because RPM lacks delayed script execution. In contrast, dpkg unpacks
dependencies and then runs the postinst scripts, so the mere binaries
can be assumed installed, the package just has not been configured.
This avoids many dependency loops (but of course not all of them). In
the RPM land, we can only use statically linked binaries or Lua in such
cases.
I have extensively used install-time scripting with Lua for packages in
the toolchain space (glibc and tzdata in particular; not all of this is
in Fedora). However, this use is controversial because some RPM
lookalikes do not implement Lua scriptlets.
Furthermore, changes in this area (such as replacing Lua with other
mechanisms such as shell scripts) are difficult to test properly because
differences in RPM or the repository contents could cause dependency
loops be broken at different points.
Thanks,
Florian
2:27 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in upstream sources
>>>> "FW" == Florian Weimer
<fweimer(a)redhat.com> writes:
FW> It's often necessary to use Lua for scriptlets which run reliably
FW> because RPM lacks delayed script execution.
I guess it depends on how delayed you want them. The ordering is
certainly well defined but it's all a bit esoteric.
But sure, Lua is there and it works. Unfortunately it lacks usability
because it really needs a standard library and more state needs to be
visible in the Lua symbol table.
In any case, I did try to play with some basic library for interfacing
with RPM stuff from within Lua scripts (debug output, manipulating macro
values, etc.) which is actually all kind of tricky but the mechanism
provided for you to add functions into the Lua symbol table is kind of
primitive and needs at least some consensus before something starts
using it.
FW> In the RPM land, we can only use statically linked binaries or Lua
FW> in such cases.
The cases where you _have_ to do that are really quite limited.
FW> I have extensively used install-time scripting with Lua for packages
FW> in the toolchain space (glibc and tzdata in particular; not all of
FW> this is in Fedora).
So, sure, glibc is tough since immediately after that package is
installed you have no scripting.
FW> However, this use is controversial because some
FW> RPM lookalikes do not implement Lua scriptlets.
For Fedora that certainly isn't a concern.
FW> Furthermore, changes in this area (such as replacing Lua with other
FW> mechanisms such as shell scripts) are difficult to test properly
FW> because differences in RPM or the repository contents could cause
FW> dependency loops be broken at different points.
Well, yes, low level distribution work is hard and the environment as
you are doing an initial OS install is, at least in the early part of
the process, extremely limited. But I don't recall a problem which
didn't have a reasonable solution. (Perhaps that depends on how you
define "reasonable" though. Some would argue that using Lua at all
isn't reasonable.)
- J<
3:36 p.m.
New subject: /bin/sh and lua;
was: Re: common location of spec files in upstream sources
On Fri, Oct 27, 2017, at 03:27 PM, Jason L Tibbitts III wrote:
FW> However, this use is controversial because some
FW> RPM lookalikes do not implement Lua scriptlets.
For Fedora that certainly isn't a concern.
For the editions that use rpm-ostree, such as Fedora Atomic Host, it is:
See:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000391.html
https://github.com/projectatomic/rpm-ostree/pull/763
https://bugzilla.redhat.com/show_bug.cgi?id=1367585
https://github.com/projectatomic/rpm-ostree/pull/980
(But currently, as linked from one of the PRs, we just override
the Fedora glibc packages' use of lua, since it's unnecessary.
It seems strange to me that Florian has time to reply on list
here and not review the patch in the BZ...)
7:07 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On Fri, 2017-10-27 at 16:36 -0400, Colin Walters wrote:
On Fri, Oct 27, 2017, at 03:27 PM, Jason L Tibbitts III wrote:
> FW> However, this use is controversial because some
> FW> RPM lookalikes do not implement Lua scriptlets.
>
> For Fedora that certainly isn't a concern.
For the editions that use rpm-ostree, such as Fedora Atomic Host, it is:
See:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000391.html
https://github.com/projectatomic/rpm-ostree/pull/763
https://bugzilla.redhat.com/show_bug.cgi?id=1367585
https://github.com/projectatomic/rpm-ostree/pull/980
(But currently, as linked from one of the PRs, we just override
the Fedora glibc packages' use of lua, since it's unnecessary.
It seems strange to me that Florian has time to reply on list
here and not review the patch in the BZ...)
FWIW, ISTR being told at some point that it's a good idea to write
scriptlets in lua because RPM should *always* be able to run lua
scriptlets, whereas at least in theory a scriptlet written in shell
script could be hit before /bin/sh is installed and thus fail to
run...presumably this can only really happen for scripts that run
during initial system installation, of course (I don't think it's
reasonably possible to remove /bin/sh from a Fedora system once it's
there).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:21 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in upstream sources
>>>> "AW" == Adam Williamson
<adamwill(a)fedoraproject.org> writes:
AW> FWIW, ISTR being told at some point that it's a good idea to write
AW> scriptlets in lua because RPM should *always* be able to run lua
AW> scriptlets, whereas at least in theory a scriptlet written in shell
AW> script could be hit before /bin/sh is installed and thus fail to
AW> run...
Well, that's why you would _have_ to do it, but those situations are
pretty limited. You could of course use it wherever you like, if you
happen to like lua, since we don't have any prohibitions against it.
Really, though, the problem is with scriptlets in general, not what
language you can write them in. I would consider anything which
pretends to work like RPM but doesn't process lua scriptlets properly to
be broken, sure, but I do still think that we should be trying to get
rid of scriptlets as much as possible. Certainly there should be
relatively few situations where we would need to have hand-written
(or even pasted in) scriptlets.
Also note that this is completely, absolutely separate from use of Lua
on the build-side of rpm specs. Honestly I don't even know whether that
is what the original poster was talking about.
- J<
8:49 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said:
FWIW, ISTR being told at some point that it's a good idea to
write
scriptlets in lua because RPM should *always* be able to run lua
scriptlets, whereas at least in theory a scriptlet written in shell
script could be hit before /bin/sh is installed and thus fail to
run...
I don't think that's true - I think an RPM with a /bin/sh scriptlet will
get a dependency on /bin/sh, so it shouldn't be installed before
/bin/sh.
The only things that should have an issue there are things that are
dependencies _of_ the package providing /bin/sh, although there is a
circular dependency there, so I'm not sure how that works today.
$ rpm -qRf /bin/sh
...
filesystem >= 3
...
$ rpm -qR filesystem
/bin/sh
...
--
Chris Adams <linux(a)cmadams.net>
8:58 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On Fri, 2017-10-27 at 20:49 -0500, Chris Adams wrote:
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org>
said:
> FWIW, ISTR being told at some point that it's a good idea to write
> scriptlets in lua because RPM should *always* be able to run lua
> scriptlets, whereas at least in theory a scriptlet written in shell
> script could be hit before /bin/sh is installed and thus fail to
> run...
I don't think that's true - I think an RPM with a /bin/sh scriptlet will
get a dependency on /bin/sh, so it shouldn't be installed before
/bin/sh.
Doesn't help for %pretrans, even if true.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:45 p.m.
New subject: /bin/sh and lua;
was: Re: common location of spec files in upstream sources
On Fri, Oct 27, 2017, at 09:58 PM, Adam Williamson wrote:
On Fri, 2017-10-27 at 20:49 -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org> said:
> > FWIW, ISTR being told at some point that it's a good idea to write
> > scriptlets in lua because RPM should *always* be able to run lua
> > scriptlets, whereas at least in theory a scriptlet written in shell
> > script could be hit before /bin/sh is installed and thus fail to
> > run...
>
> I don't think that's true - I think an RPM with a /bin/sh scriptlet will
> get a dependency on /bin/sh, so it shouldn't be installed before
> /bin/sh.
Doesn't help for %pretrans, even if true.
%pretrans was covered in the thread; direct link:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000396.html
So we could patch RPM to not execute them on initial install, but eh,
I don't care enough - rpm-ostree already ignores them, doesn't hurt
anything if they stay in lua.
6:25 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On 10/28/2017 03:49 AM, Chris Adams wrote:
Once upon a time, Adam Williamson <adamwill(a)fedoraproject.org>
said:
> FWIW, ISTR being told at some point that it's a good idea to write
> scriptlets in lua because RPM should *always* be able to run lua
> scriptlets, whereas at least in theory a scriptlet written in shell
> script could be hit before /bin/sh is installed and thus fail to
> run...
I don't think that's true - I think an RPM with a /bin/sh scriptlet will
get a dependency on /bin/sh, so it shouldn't be installed before
/bin/sh.
That's not true in general if your package is in turn a dependency of
whatever provides /bin/sh. That affects a dozen or so packages in
Fedora, according to a quick check.
Thanks,
Florian
6:31 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On 10/27/2017 10:36 PM, Colin Walters wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1367585
(But currently, as linked from one of the PRs, we just override
the Fedora glibc packages' use of lua, since it's unnecessary.
It seems strange to me that Florian has time to reply on list
here and not review the patch in the BZ...)
I don't know what to say on the BZ. The current spec file is buggy:
using %posttrans for this step is wrong because it means that many
scriptlets will run with the wrong locale archive. The proposed patch
does not fix this issue.
Thanks,
Florian
6:33 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On 10/27/2017 09:27 PM, Jason L Tibbitts III wrote:
>>>>> "FW" == Florian Weimer
<fweimer(a)redhat.com> writes:
FW> It's often necessary to use Lua for scriptlets which run reliably
FW> because RPM lacks delayed script execution.
I guess it depends on how delayed you want them. The ordering is
certainly well defined but it's all a bit esoteric.
I don't think the point where the cycle is broken is well-defined.
Doesn't it depend on the transaction contents?
But sure, Lua is there and it works. Unfortunately it lacks
usability
because it really needs a standard library and more state needs to be
visible in the Lua symbol table.
The posix module that RPM provides internally is quite useful. The
problem is that it's not luaposix, so it can be confusing initially.
FW> Furthermore, changes in this area (such as replacing Lua with
other
FW> mechanisms such as shell scripts) are difficult to test properly
FW> because differences in RPM or the repository contents could cause
FW> dependency loops be broken at different points.
Well, yes, low level distribution work is hard and the environment as
you are doing an initial OS install is, at least in the early part of
the process, extremely limited.
Installs are the easy part. Upgrades are much harder because there are
so many more moving parts.
Thanks,
Florian
12:41 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
Hi Florian,
One problem is that there is a "rpm lua" and a "system lua" making it
hard to switch between scriplets and actual scripts.
As for bashisms, I don't seen the point of struggling for a smaller shell when
everything lately has been about wrapping code in fatter and fatter virtual delivery
enveloppes.
Regards,
--
Nicolas Mailhot
1:58 p.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in upstream sources
>>>> "RPH" == R P Herrold
<herrold(a)owlriver.com> writes:
RPH> I noticed in the Scripts languages section the ** absence ** of
RPH> /bin/sh (and not 'bash' with its 'bashisms'), and lua
There's no "Scripts languages" section in the packaging guidelines as
far as I'm aware. Are you referring to the "Domain Specific Guidelines"
section at the end which lists separate guideline pages that exist?
And /bin/sh simply is bash in Fedora.
RPH> This may merit some discussion here before I edit the wiki
Well you can't edit Packaging:Guidelines (or other pages under
Packaging:), but you can file issues and submit drafts to the packaging
committee:
https://fedoraproject.org/wiki/Packaging_Committee
https://pagure.io/packaging-committee
- J<
8:36 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in
upstream sources
On Fri, 27 Oct 2017, Jason L Tibbitts III wrote:
>>>>> "RPH" == R P Herrold
<herrold(a)owlriver.com> writes:
RPH> I noticed in the Scripts languages section the ** absence ** of
RPH> /bin/sh (and not 'bash' with its 'bashisms'), and lua
I was referring to: section 37 ("Scripting inside of spec
files ")
https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_s...
-- Russ herrold
9:33 a.m.
New subject: /bin/sh and lua; was: Re: common location of spec files in upstream sources
>>>> "RPH" == R P Herrold
<herrold(a)owlriver.com> writes:
RPH> I was referring to: section 37 ("Scripting inside of spec files ")
RPH>
https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_s...
Well, OK. I mean, Lua is right there so I'm not sure why you say it
would need to be added, and I don't see why bash would be there since by
default the scriptlets are all already in bash. The intent of that
guideline is to cover the case where you need to call some other program
to, say, parse some data out of a file or make a substitution in %build,
%prep or %install. It (explicitly) doesn't cover %post of the like at
all, so it's purely an rpmbuild thing.
The idea is that we would really rather people not go calling tcl or
whatever in their scriptlets and thus moving tcl into the list of things
you need to build in order to build other things.
That said, the guideline is rather old and might not really reflect
current attitudes. My understanding of current attitudes is that, say,
gawk and sed would be preferred to Perl (so #2 and #3 on that list would
be switched). But I could certainly be wrong.
- J<
7:49 p.m.
On Thu, 2017-10-26 at 16:02 -0500, Mátyás Selmeci wrote:
Hi,
For upstream projects that provide spec files in their repositories,
do
y'all tend to see a common location for the spec files? Like
dist/<name>.spec or rpm/<name>.spec, etc. My organization is trying
to
standardize on a location for the software we maintain, and it would
be
better to use something that many in the open source community also
use.
May be in the root of the project because is just one file , do a
directory to have one file is not organization , for example gammu [1]
do that .
[1] https://github.com/gammu/gammu
Thanks,
-Mat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Sérgio M. B.
2368
days inactive
2372
days old
23 comments
14 participants
participants (14)
-
Adam Williamson -
Athos Ribeiro -
Chris Adams -
Colin Walters -
Fernando Nasser -
Florian Weimer -
Jason L Tibbitts III -
Mátyás Selmeci -
Neal Gompa -
nicolas.mailhot＠laposte.net -
R P Herrold -
Sérgio Basto -
Vít Ondruch -
William Moreno