Broken Symlinks
by John Dodson
Hi list,
I'm new to this list but have had a hard time convincing redhat people that
broken symlinks are bad! (I'm not going to bother trying to convice you ;-)
What I would like to do is get a "package" to take responsibility for the many
broken symlinks out there. So that at least a broken symlink can be assigned to
a specific package the owner of which thinks (sic) that the symlink is
"required" from his/her perspective. (I won't say that the code should be more
intelligent & create a symlink if it is really necessary & remove it when it's
broken as that would expect too much)
Please see,
https://access.redhat.com/support/cases/#/case/01326479
for more detail.
Generally many packages create symlinks, but don't "own them", I'd like to
change that. eg. kernel packagages if the source is not installed.
Try, find / -type l -exec file "{}" \; |grep broken
Cheers
johnd
John Dodson | Bosch Research Engineering & Computing Facility Manager,
| Network Manager Medical Sciences, Electrical/Electronics/Control
| Telecommunications Engineer Physiology/School of Medical Sciences
The University of Sydney
Rm N252,Anderson Stuart Building (F13) Eastern Avenue,
The University of Sydney|NSW|2006|Australia.
T +61 2 9351 5246 | F +61 2 9351 2058 | M +61 4 1459 7557
E johnd(a)physiol.usyd.edu.au | W http://www.physiol.usyd.edu.au/johnd
ABN:15 211 513 464 CRICOS Number: 00026A
I'd rather be on OTI... http://www.bio.usyd.edu.au/OTI
https://www.google.com.au/maps/place/One+Tree+Island,+Queensland/@-23.566...
8 years, 6 months
Proposal: Remove BuildRequires: exceptions from the guidelines
by Jason L Tibbitts III
TL;DR: There's a proposal for nuking the list of BuildRequires
exceptions from the packaging guidelines.
Important note: this is just an idea. We're not currently changing the
guidelines based on this. Nothing is set in stone. It may end up that
nothing happens. Don't panic.
A couple of times recently, people have floated proposals to the FPC
about removing certain things from the buildroot. (Specifically, perl
and gcc*.) And the bottom line for these is that while FPC tries to
maintain a list of BuildRequires: exceptions, this is really up to
releng and whatever rpm happens to pull in at any particular time.
This means that whatever list FPC maintains, it's going to get outdated
eventually, and giving packagers the idea that they don't have to
actually specify all of their dependencies restricts what releng can do
and, perhaps, what dependencies the RPM package can drop without
breaking builds.
So, the generally stated proposal:
I would like to get FPC out of the business of specifying this list of
exceptions, and instead just indicate that packagers should completely
specify their dependencies.
My specific proposal can be seen in
https://fedorahosted.org/fpc/ticket/497; the draft is at
https://fedoraproject.org/wiki/User:Tibbs/BuildReqDraft2. You can use
the history tab to see the differences between that and the current
guidelines.
Now, the real issue is in what packagers can depend upon. Obviously you
have RPM and an environment necessary to build a package (which means
you have to have a shell to execute the scripts that make up the RPM
sections, and redhat-rpm-config, and whatever RPM happens to use to
execute %patch, which I guess could be some internal library if the RPM
devs wanted). But what else? That's the open question.
The draft currently says:
---
You may assume that you have everything necessary for RPM to function
and process your spec file (so of course RPM is present, along with
redhat-rpm-config and what is necessary for RPM to apply patches, unpack
archives, and run the shell scripts which make up the spec file
sections.) You should not assume any other packages are present, as RPM
dependencies and anything brought into the buildroot by the build system
may change over time.
---
Honestly, I'm not completely satisfied with that but I can't come up
with anything better. Polite discussion is welcomed and encouraged.
- J<
8 years, 7 months
Go Packaging Guidelines: What's next?
by Adam Miller
Hello all,
I've noticed that the Go (golang) Packaging Guidelines Draft[0]
document has been stagnant for a while now and I'm curious what the
next steps should be? Does this need to go through FESCo?
Also, since Go is statically compiled by default is this something
we need to get an exception from FESCo similar to OCaml[1]?
Another topic of note is bundled libraries. The upstream Go
community seems pretty content with just bundling in their
dependencies since it's all statically linked anyways (yes, you can
dynamically link with gcc-go but I've yet to find a single project out
in community space doing that).
For some popular Go projects the dependency list is over 100
deps[2] and are managed with something similar to Godep[3], I'm not
sure how realistic it is for packagers to be expected to maintain that
many dependencies. This also begs the question that if we do require a
packager to maintain them, what happens if another project requires a
different version of that dep? (This is similar in nature to what I
like to call "ruby bundler hell").
If there were to be some sort of approval for these bundled
libraries, should there be a defined specification of which Go
dependency managers are supported for sake of security response so
that we can check for packages that need rebuilding when a
vulnerability is found? What kind of changes would be necessary for
build tooling there? (Maybe something in this area I'm not thinking
of?)
I wanted to at least get this conversation going because it
appears there's already a number of Go packages in Fedora at this time
without any approved standard and as the language continues to gain
popularity I can only assume that number will increase.
At the time of this writing, on my laptop running Rawhide:
$ dnf search golang | wc -l
279
Thank you,
-AdamM
[0] - https://fedoraproject.org/wiki/PackagingDrafts/Go
[1] - https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.27...
[2] - https://github.com/openshift/origin/blob/master/Godeps/Godeps.json
[3] - https://github.com/tools/godep
8 years, 7 months
Shared libraries unversioned .so symlinks packaging
by dani
Hi,
When building gcc 5.1 rpm (based on f22 spec) to a different prefix I
get a list of .so unpackaged files:
/opt/gnu/gcc/5.1.0/lib64/libasan.so
/opt/gnu/gcc/5.1.0/lib64/libatomic.so
/opt/gnu/gcc/5.1.0/lib64/libcilkrts.so
/opt/gnu/gcc/5.1.0/lib64/libgcc_s.so
/opt/gnu/gcc/5.1.0/lib64/libgfortran.so
/opt/gnu/gcc/5.1.0/lib64/libgomp-plugin-host_nonshm.so
/opt/gnu/gcc/5.1.0/lib64/libgomp.so
/opt/gnu/gcc/5.1.0/lib64/libitm.so
/opt/gnu/gcc/5.1.0/lib64/liblsan.so
/opt/gnu/gcc/5.1.0/lib64/libmpx.so
/opt/gnu/gcc/5.1.0/lib64/libmpxwrappers.so
/opt/gnu/gcc/5.1.0/lib64/libobjc.so
/opt/gnu/gcc/5.1.0/lib64/libquadmath.so
/opt/gnu/gcc/5.1.0/lib64/libstdc++.so
/opt/gnu/gcc/5.1.0/lib64/libtsan.so
/opt/gnu/gcc/5.1.0/lib64/libubsan.so
I know the usual solution is to place such symlinks in the <lib>-devel
package, but for most of those libs there is no devel counterpart, so
I'm wondering what are best practices in this case.
I figure I can
1. Just ignore them (I have %global _unpackaged_files_terminate_build 0)
2. Remove them in %install
3. Add them to their respective %files lib
4. Create an %files lib-devel for each one
Which is preferred, if at all?
As a potential follow-up: If 1 or 3, why bother creating them in the
first place?
8 years, 7 months
Re: [Fedora-packaging] /usr/share vs /usr/libexec
by Sérgio Basto
Hi,
On Qua, 2015-04-22 at 08:17 -0600, Ken Dreyer wrote:
> On Wed, Apr 22, 2015 at 8:06 AM, Miloslav Trmač <mitr(a)redhat.com> wrote:
> > Hello,
> >> I confess I've only seen /usr/libexec used for add-on utilities, but
> >> now I'm curious.
> >>
> >> Does it make more sense for these sort of scripts to live in
> >> /usr/libexec, or in /usr/share?
> >
> > /usr/libexec. From (info standards):
> >
> >> `libexecdir'
> >> The directory for installing executable programs to be run by other
> >> programs rather than by users.
> >
>
> The thing that threw me is that I poked around in /usr/share and found this:
>
> $ cat /bin/createrepo
> #!/bin/sh
> exec /usr/share/createrepo/genpkgmetadata.py "$@"
>
> Given what you're saying, would this be considered a bug in createrepo?
>
> There are a lot of Python files in /usr/share, but createrepo was one
> that's the most obvious to me (simply shelling out to a file in
> /usr/share). Similarly, there are a lot of executable files: (find
> /usr/share/ -executable -type f) Are these all bugs?
I'm adding packaging Mailing List, seems to me that we can get more help
here.
I have a lot of questions on this topic, not just /usr/share
vs /usr/libexec also vs /usr/lib .
>From what I understand, this is a problem that was created from Debian
translations. Debian don't have /usr/lib64/ and put all in /usr/lib, so
when we are packaging things that came "debianized". We got problems
when have things in /usr/lib/package and aren't libs and or are noarch
things. What we should do ? put it in /usr/libexec ? in /usr/share ? or
have a /usr/lib even for x86_64 ?
We got weird examples: /usr/lib/rpm, /usr/lib/systemd/
and /usr/lib/udev/ shouldn't be in /usr/share/rpm etc ?
Thanks,
--
Sérgio M. B.
8 years, 7 months
Summary/Minutes from today's FPC Meeting (2015-04-23 16:00 - 17:30 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:24 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-04-23/fpc.2015-04-...
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:24)
* LINK:
https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee
(tibbs|w, 16:05:32)
* Schedule (geppetto, 16:08:33)
* LINK:
https://lists.fedoraproject.org/pipermail/packaging/2015-April/010604.html
(geppetto, 16:08:37)
* #525 Request for bundling exception: plotnetcfg, contains parson
library (geppetto, 16:08:51)
* LINK: https://fedorahosted.org/fpc/ticket/525 (geppetto, 16:08:56)
* ACTION: Allow tmp. bundling exception for F22, but use at least
static. lib for F23. (+1:5, 0:0, -1:0) (geppetto, 16:26:27)
* #524 static UID for ceph (geppetto, 16:26:41)
* LINK: https://fedorahosted.org/fpc/ticket/524 (geppetto, 16:26:48)
* ACTION: We don't see the point, given that Debian won't be
compatible and you have fixup scripts. If the fixup scripts take an
annoying amount of time to run, then we might reconsider.
(geppetto, 16:47:13)
* #520 [Guidelines Draft] Per-Product Configuration Defaults v2
(geppetto, 16:47:44)
* LINK: https://fedorahosted.org/fpc/ticket/520 (geppetto, 16:47:45)
* LINK:
https://fedoraproject.org/wiki/User:Sgallagh/Per-Product_Configuration_Pa...
(geppetto, 17:06:03)
* LINK:
https://fedoraproject.org/w/index.php?title=User:Sgallagh/Per-Product_Con...
(racor, 17:06:14)
* ACTION: Per-Product Configuration Packaging (+1:6, 0:0, -1:0)
(geppetto, 17:24:19)
* Open Floor (geppetto, 17:24:29)
Meeting ended at 17:30:42 UTC.
Action Items
------------
* Allow tmp. bundling exception for F22, but use at least static. lib
for F23. (+1:5, 0:0, -1:0)
* We don't see the point, given that Debian won't be compatible and you
have fixup scripts. If the fixup scripts take an annoying amount of
time to run, then we might reconsider.
* Per-Product Configuration Packaging (+1:6, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Allow tmp. bundling exception for F22, but use at least static. lib
for F23. (+1:5, 0:0, -1:0)
* We don't see the point, given that Debian won't be compatible and
you have fixup scripts. If the fixup scripts take an annoying amount
of time to run, then we might reconsider.
* Per-Product Configuration Packaging (+1:6, 0:0, -1:0)
People Present (lines said)
---------------------------
* geppetto (131)
* tibbs|w (94)
* sgallagh (75)
* racor (25)
* mbooth (14)
* tomspur (14)
* orionp (11)
* zodbot (10)
* lubko (8)
* jbenc (7)
* tibbs (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 7 months
qt-examples, libqxt-devel - Need exceptions?
by Gerald B. Cox
I am working on packaging a program which includes a very small subset of
files from these packages.
>From qt-examples, there are four files.
>From libqxt-devel, there are three files.
All of the files have been modified for use by the application.
I have done a search to see if these rpms are build requires for other
packages:
dnf repoquery --whatrequires qt-examples
dnf repoquery --whatrequires libqxt-devel
In both cases I receive zero hits.
I'm thinking now that qt-examples doesn't really qualify as a "library".
It is described as
"Programming Examples for Qt" - which to me means the intent is to take
what you need and
modify. The intent was never that this be a "library".
In the case of libqxt-devel: http://dev.libqxt.org/libqxt/wiki/Home
The website says: "This package is no longer maintained. Qxt will likely
not work with newer Qt versions due to usage
of internal api. We recommend that you pick out the parts you want instead
of using the entire libqxt."
Which is exactly what the developer did.
Considering the above, I'm thinking no exception is required for the
inclusion of these 7 files. Comments? I don't
want to waste peoples time by going through the exception process if it
isn't needed.
Thanks very much!
8 years, 7 months
