Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I
would like to announce that the packaging guidelines have some
extensions (not really new) that will be stricter enforced than they
used to be.
Currently a common rule to be 'ignored' or packagers are not aware is
around the topics of:
- .Changes entries
- Patches
First, the .changes entry (rpm changelog) surves two purposes:
- News for the user
- History tracking of packaging changes (often referenced in bugs to
verify if a user has the latest packaging bugfixeS).
A simple "Update to version x.y.z" is, as before, not accepted. There
should be some buzz around the update for the user; some major reasons
to the upgrade should be listed
Changes on the package itself should be mentioned in a way that any
other contributor to the same package can follow traces of why
something is the way it is. Commonly, Added (build)dependencies are
interesting to be seen, special hacks to make something work in a
particular way [..]: Always consider that package maintenance is a
distributed task and various contributors need to be able to step up
at will.
Patches:
The rules about patches are listed at
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
Most prominent is likely the mentioning of the patches life cycle,
which forces you to mention additions and removals of patches in the
changelog. As history shows, this can be helpful if a patch got
removed, and later a regression is reported; finding out when a patch
was removed can be crucial in reconstructing feature sets (including
contacting the contributor that dropped it.. which is easily extracted
from the .changes if listed)
The main appeal is to the devel project maintainers / reviewers, to
keep out for those rules, to live according to them, as it is
frustrating for everybody if a package needs to be declined by the
Factory Review team:
- The dev prj maintainer is the one getting the 'decline' (as it was
usually a forwarded request), which often leaves the 'fixing' to the
devel project maintainers, where the 'originator' of the fix would
have been willing to actually do that...
And the Factory Review team also prefers to see complying submissions
to having to reject SRs... reject is not fun for anybody!
Looking forward to many more SRs to accept!
Dominique / DimStar
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I sent the httrack package to security a couple weeks ago. It builds,
but with a few rpmlint issues.
I thought I would clean up the one about the shared library needing to
be split out to its own package.
I've tried to do that in home:gregfreemyer:branches:security > httrack
The diff is:
https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=security…
I've tried multiple ways to call ldconfig.
But my build always fails with:
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin
(Badness: 300) /usr/lib64/libhtsjava.so.2.0.46
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin
(Badness: 300) /usr/lib64/libhttrack.so.2.0.46
[ 218s] This package contains a library and provides no %post
scriptlet containing a
[ 218s] call to ldconfig.
The spec file currently has:
===
%post
/sbin/ldconfig /usr/lib64
%postun
/sbin/ldconfig /usr/lib64
===
I've tried the basic versions as well.
==
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
==
%post
/sbin/ldconfig
%postun
/sbin/ldconfig
==
Can anyone tell me what's going on?
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I think Requires and BuildRequires are disjoint / independent.
I have a package that has about 20 Requires. I'd like to have a
%check section for it, but I'll need all those requires at build time
as well to do that.
Is there a clean solution?
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Since SuSEconfig is dead now, I'm blacklisting the whole directory
/etc/conf.d in rpmlint.
Also, I'm adding a check to rpmlint for the directories /etc/modules-
load.d and /etc/tmpfiles.d since those should contain only user files,
system wide configuration is in /usr/lib/modules-load.d and
/usr/lib/tmpfiles.d.
How shall we handle /etc/systemd ? Currently systemd installs some files
into it - is it the only package doing so and thus should we add an
rpmlintrc allowing it in systemd as an exception? Or any better ideas to
handle it?
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Fellow packagers and pythonistas,
i'd like to notify you about a proposed change to the way Python installs its
packages, and give you a chance to object before it is put into effect.
This has nothing to do with the "versioned python" proposal.
TL;DR version:
Currently, python is configured to install packages into
/usr/local/lib/pythonX.Y/site-packages, unless you specify "--prefix=/usr". This
mimicks autotools behavior, but diverges from upstream.
If there are no significant objections, I'm going to restore the default
behavior where "/usr" is the default prefix.
Packages installed in /usr/local will still be recognized, it just won't be the
default install location anymore.
Detailed version:
While investigating possible solutions to bnc#658604 (python user install scheme
broken, [1]), i came to revisit the decision to make SUSE's python install
modules into /usr/local by default.
A little background: this feature came to be as a response to a pair of bugs,
bnc#149809 [2] and bnc#149843 [3]. The original reporter argues that /usr/local
is the right place for locally-installed software and that Python should not
deviate from customary (i.e. autotools) behavior in this regard.
Python should auto-recognize modules installed in the /usr/local hierarchy, and
for consistency and convenience's sake, should install in there by default as well.
The former request is reasonable, and back then i thought that the latter is
reasonable as well.
(also, back then i wasn't on the job for very long, i made the change, didn't
tell anyone about it and broke about a million of other people's packages. oh
those were the days. sorry again if you were affected.)
Six years later, i still think it's the right thing to do, but i don't think we
should actually be doing it.
Arguments basically boil down to one of Python's core principles, "practicality
beats purity". But for completeness, here's what i came up with.
For installing to /usr/local:
+ it's what FHS tells us, with some good reasoning (read-only /usr and so on)
+ it's what autotools do
+ the /usr hierarchy remains untainted by files outside of rpm's control
+ and conversely, the user has all of her site-local packages in /usr/local, not
mingled with "managed" installations
(unlike e.g. Perl, Python has no official mechanism for separating "site"
packages and "vendor" packages. this provides such distinction)
Against:
- AFAIK, we're the only ones doing it
- upstream python doesn't recognize the distinction and there is no support for
it in the libraries
- to expand on that point, there is no "right" place to patch this behavior in
- a correct patch for the new behavior wouldn't be too complex, but it would not
be upstreamable. No patch is better than one patch.
- modules don't like to be installed in locations they can't query through
python's sysconfig methods
- third-party python packagemanagers/installers might not recognize our
intentions and would need to be patched separately
Also, i'm not really aware of anyone reaping any benefits from our current
config. So, if you have anything good to say about the way we do it now, here is
your chance.
I'll wait until next week, and if no significant objections are raised, i'll
push this change into Factory.
m.
[1] "Python distutils setup does not allow user installation of Python packages"
https://bugzilla.novell.com/show_bug.cgi?id=658604
[2] "python path does not contain /usr/local"
https://bugzilla.novell.com/show_bug.cgi?id=149809
[3] "Python's site-packages should contain a directory in /usr/local"
https://bugzilla.novell.com/show_bug.cgi?id=149843
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I have mailed packaging mailing list earlier
<http://lists.opensuse.org/opensuse-packaging/2012-09/msg00123.html>
regarding packaging guidelines for Lua packaging which probably did not
get enough attention.
Following a mail to the opensuse-buildservice regarding lua packages
development
<http://lists.opensuse.org/opensuse-buildservice/2012-09/msg00144.html>
I would like to propose the following packaging guidelines for Lua since
the projct does not have one.
1) The main development should be taking place in devel:languages:lua
and therefore devel:languages:misc should be droped as the devel repo
for Factory.
2) various lua packages that are scattered around the OBS should be
developed in devel:languages:lua
Guidelines for Lua packages
Macros are already defined by the lua and lua51 packages in
devel:languages:misc
# RPM macros for Lua
# The major.minor version of Lua
%lua_version %(lua -e 'print(_VERSION)' | cut -d ' ' -f 2)
# compiled modules should go here
%lua_archdir %{_libdir}/lua/%{lua_version}
# pure Lua modules should go here
%lua_noarchdir %{_datadir}/lua/%{lua_version}
* Addon packages
Lua add-on packages should generally follow the naming scheme of
lua(version)-PKG_NAME -- e.g.
lua51-luafilesystem -- tobe used with lua version 5.1
lua-luafilesystem -- tobe used with lua version 5.2
* Development Packages
Development packages should have devel suffix added to the package name
lua(version)-PKG_NAME-devel
Example
lua51-luafilesystem-devel
* Documentation packages
If a package has huge documentation or is just a doc package then naming
should be
lua(version)-PackageName-doc and should be installed to %_defaultdocdir
/usr/share/doc/packages/lua-{PKG_NAME}-doc/*
Many upstream Lua developers use LuaRocks to distribute their modules.
Therefore we probably should be finding a way to integrate luarocks in
our build system and possibly provide a packaging mechanism similar to
py2pack of python
Comments will be appreciated
Togan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I got this https://build.opensuse.org/request/show/135388
What do you think? It actually solves a real problem: the model of
having a copy of everything in our servers doesn't scale. Specially
with big game data.
Problems I can think of:
- You don't have control over the external servers. Somebody could
modify the files there add hack into users machines.
- No information about the files is stored in the RPM database. It's
impossible to verify the integrity of the installed package.
- It just looks bad, ugly and fragile.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
According to Packaging Patch Guidelines at
<http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines> use of
quilt is exampled as follows
quilt ref --s --d -p1
However neither the man page nor the quilt refresh -h provides the
options --s and --d
It would be nice to know what they are suppose to mean
Thanks
Togan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
FYI,
a colleague of mine just did these changes:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think one of our oldest scripts in our SuSE Linux/SUSE Linux/openSUSE
and SUSE Linux Enterprise history is now finally gone: /sbin/SuSEconfig
R.I.P.
https://fate.suse.com/100011https://build.opensuse.org/request/show/135139
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think we have fixed all the packages that used SuSEconfig and will
blacklist it now in rpmlint,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I've added now a README.packaging.txt to the packages aaa_base and
rpmlint to point out which files are unter version control and how to
update.
If you have a package that is basically maintained in a version control
system, I suggest you add some information for packagers in a similar
way.
For reference, this is the README from aaa_base:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This package should use just the content of the git tree. If you need
to make changes, you have the following options:
* Make them in git and update the package from git (you can send merge
request if you don't have write access)
* Create a patch, add the patch to the package and let one of the
aaa_base packagers commit it for you
The online repository is at:
http://gitorious.org/opensuse/aaa_base
For building the package from git run the service directly:
osc service disabledrun
Note that aaa_base.spec and aaa_base.changes are not part of the git
repo.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm also interested in better ideas to point out the version control
relationship,
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org