openSUSE Packaging September 2012

packaging@lists.opensuse.org

62 participants
49 discussions

[opensuse-packaging] Packaging Guideline enforcement

by Dominique Leuenberger a.k.a DimStar

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

8 years, 8 months

[opensuse-packaging] ldconfig - I'm frustrated

by Greg Freemyer

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

9 years, 1 month

[opensuse-packaging] Is there a macro for both BuildRequires and Requires?

by Greg Freemyer

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

9 years, 6 months

[opensuse-packaging] New rpmlint checks for /etc/conf.d and systemd directories

by Andreas Jaeger

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

9 years, 6 months

[opensuse-packaging] python installing modules to /usr/local by default - good or bad?

by Jan Matejek

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

9 years, 7 months

[opensuse-packaging] RFC: Lua packaging guidelines

by Togan Muftuoglu

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

9 years, 7 months

[opensuse-packaging] Download BIG data in %post script. What do you think?

by Cristian Morales Vega

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

9 years, 7 months

[opensuse-packaging] Quilt refresh options

by Togan Muftuoglu

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

9 years, 7 months

[opensuse-packaging] SuSEconfig is gone

by Andreas Jaeger

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/100011 https://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

9 years, 7 months

[opensuse-packaging] Suggestion: Add READMEs for version control access

by Andreas Jaeger

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

9 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2012