December 2005 - openSUSE Packaging - openSUSE Mailing Lists

Where to place template files
by Richard Bos 12 Jan '06

12 Jan '06

I have a whole bunch of template files, where to place/locate template files? Is this /etc/<package>/... or would it be better to put those in /usr/share/<package>/...? Below a list with files, perhaps it helps tp detemine the location? ./etc/kolab/amavisd/templates/en_US/charset ./etc/kolab/amavisd/templates/en_US/template-dsn.txt ./etc/kolab/amavisd/templates/en_US/template-spam-admin.txt ./etc/kolab/amavisd/templates/en_US/template-spam-sender.txt ./etc/kolab/amavisd/templates/en_US/template-virus-admin.txt ./etc/kolab/amavisd/templates/en_US/template-virus-recipient.txt ./etc/kolab/amavisd/templates/en_US/template-virus-sender.txt /etc/kolab/templates/amavisd.conf.template ./etc/kolab/templates/clamd.conf.template ./etc/kolab/templates/cyrus.conf.template ./etc/kolab/templates/DB_CONFIG.slapd.template ./etc/kolab/templates/fbview.conf.template ./etc/kolab/templates/freebusy.conf.template ./etc/kolab/templates/freshclam.conf.template ./etc/kolab/templates/httpd.conf.template ./etc/kolab/templates/httpd.local.template ./etc/kolab/templates/imapd.conf.template ./etc/kolab/templates/imapd.group.template ./etc/kolab/templates/kolab.conf.template ./etc/kolab/templates/kolab_smtpdpolicy.conf.template ./etc/kolab/templates/ldap.conf.template ./etc/kolab/templates/ldapdistlist.cf.template ./etc/kolab/templates/ldaptransport.cf.template -- Richard Bos Without a home the journey is endless

2 1

gimp-beta
by James Ogley 30 Dec '05

30 Dec '05

Just uploading new gimp-beta[-devel] packages to the usr-local-bin repo/component/channel. 10.0-i[56]86 + src -- James Ogley james(a)usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org

1 0

kdebindings3-python and kdegraphics3-pdf dependency problem
by Richard Bos 24 Dec '05

24 Dec '05

I get the following problem when updating kdebindings3-python and kdegraphics3-pdf: The following packages have unmet dependencies: kdebindings3-python: Depends: python-qt (= 3.5.0-9) but 3.5.0-8 is to be installed kdegraphics3-pdf: Depends: xpdf-tools but it is not installable Seems a bug in the packages to me, can I report that here or should I go somewhere else? -- Richard Bos Without a home the journey is endless

1 0

"Virtual"/"meta" packages
by Pascal Bleser 23 Dec '05

23 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another idea... let's call it "meta" or "virtual" packages... Make empty packages that pull several dependencies using their Requires tags to make packagers' life easier. e.g. Name: meta-c++-devel Version: 1.0.0 Release: 1 Requires: make libtool autoconf automake gcc-c++ Requires: libstdc++ libstdc++-devel libgcc glibc-devel (empty files, empty %setup, empty %build, empty %install) Note that such a "meta" package should be arch-specific (not "noarch") because it could be that on some architecture you need different packages than on others (e.g. an x86-optimized assembler would be included in the "meta-c++-devel" package on x86 and x86_64, but not on ppc or s390). That way, when packagers need to "BuildRequires" the C++ development environment for another package, it's just a matter of: Name: libfoo++ Version: 3.4.5 Release: 39 ... BuildRequires: meta-c++-devel ... SUSE's y2pmbuild already partly offers that functionality by expanding "virtual" names in "neededforbuild" to a set of real dependencies, but the issue with that approach is that it works only when using y2pmbuild. The solution above would work with any package manager (yast2, smart, yum, apt, ...) and with any RPM building frontend (rpmbuild, y2pmbuild, abuild, ...), and could even easily "hide" the gory details of what packages are required on 10.1, 10.0, on 9.3, ... to have a specific environment (e.g. on SUSE < 9.2, it's "libjpeg" whereas on SUSE >= 9.2 it's "libjpeg libjpeg-devel"). Mauricio "netmask" Teixeira and I talked about that idea, as Mauricio told me that Connectiva has that approach with so-called "task" packages (task-c++-devel, etc...). They also use it to do the same as SUSE Linux' "selections" (*.sel files in yast2 repositories), e.g. "task-mail-server", but that's a different story ;) I could really use such a "meta-gnome-devel" package ;))) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpnsEr3NMWliFcXcRAq2rAKCV2t6NNCaNW4R7LBr0tZS98ONIWwCgptY0 CGMefs6HAWaP0Djcd6v1cCc= =ptnB -----END PGP SIGNATURE-----

3 3

[Proposal] Suggests/Enhances Support in RPM/YaST
by Marcus Rueckert 21 Dec '05

21 Dec '05

hi, beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature: Enhances/Support Flags for a rpm. Some people might know them from Debian. Sadly RPM doesnt honor those flags yet. But SmartPM and the new YaST Package manager will support them. Semantics behind the 2 rpm tags --------------------------------- Basically both work similar to Provides/Requires. Atm the information will be just passed into the base package. RPM wont tell you about the relation ship. That work has to be done by high level tools. 1. Suggests ============= "Suggests" is a weak "Requires". You can suggest big packages, you dont want to enforce. A prominent example might be the hard requirement in taskjuggler to kdepim. Especially Gnome users dont like that much. 2. Enhances ============= "Enhances" can be used to promote addon packages. An amarok addon could declare itself as an enhancement of the amarok base package. That way we dont have to know all possible addon packages in the base package, but still be able to present the information to the user. Klaus Kaempf mentioned as another possible use case enhances on hardware detected in the box. Atm we install the synaptic driver in the default selection without checking if the box has a synaptics touch pad. xorg-xinput-synaptics could specify "Enhances: hwinfo(x11:synaptic-touchpad)" and SaX2 will only ask to install this rpm if the hardware is really found. Possible Solution inside YaST ------------------------------- Below the package listing you have this small info box where you can read the package description/technical informations/Requires|Provides list. An additional tab could be added to this area and the list of additional packages could be shown there. Or the usual dependency solving dialog could be presented. comments/critics welcome. Marcus p.s.: the original bug for this proposal https://bugzilla.novell.com/show_bug.cgi?id=136757

10 14

Gaim 2.0 beta
by James Ogley 21 Dec '05

21 Dec '05

Before I do the honours for 10.0, was anyone else planning to package up the new beta of gaim? James -- James Ogley james(a)usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org

4 9

Re: [opensuse-packaging] kdenetwork3-InstantMessaging vs kopete (fwd)
by Will Stephenson 19 Dec '05

19 Dec '05

> From: Pascal Bleser <pascal.bleser(a)skynet.be> > > I'd like to discuss the fact that the kopete package is called > "kdenetwork3-InstantMessaging". After doing some research (and with some > help), I know that the decision to name that package this way comes from > SUSE (and not from the KDE team). That's partly right - kde svn modules are all packaged as kmodulename3, then any subpackage splits are at the discretion of the SUSE KDE maintainers. > I think it's not a good idea to name kopete that way, although the name > isn't the issue, but the version number. In fact, it's e.g. > kdenetwork3-InstantMessaging-3.5.0, but in reality it's some kopete version > (e.g. 0.11.x) This is an issue for every KDE application - kdepim3 contains kmail 1.9. It's only a problem in cases like this where the app team decides to do an out-of-kde-module release. > This raises a number of issues, where the most important is: now there's > going to be a kopete 0.12.0 very soon... how are we supposed to name/number > the package ? > > - we can't name it kdenetwork3-InstantMessaging-3.5.1, because when KDE > 3.5.1 will be released (possibly with a different kopete version but, most > importantly, built against another version of kdelibs3) it will collide > - we can't name it kopete either (with a > Conflicts:kdenetwork3-InstantMessaging) because end users won't see that as > an upgrade of kdenetwork3-InstantMessaging > - we /could/ use the release to provide an upgrade, but that's > a) misusing the release tag for what is actually a different version > number b) a pain to maintain, because maybe SUSE releases an update > kdenetwork3-InstantMessaging (with kopete 0.11.x) and then we'd have to > re-package it with a higher release number than SUSE > c) just an evil > workaround and trickery whereas the issue should be solved by giving the > package its correct name in the first place > > Could someone from SUSE please provide some feedback on this ? Stephan ? AJ > ? Would it be possible to rename kdenetwork3-InstantMessaging-3.5.0 to > kopete-0.11.x ? To me, it really doesn't make any sense to call it > "kdenetwork3-InstantMessaging", kopete is not even tightly bound to a > specific KDE release, it just creates issues for community packagers who > want to provide packages of the latest kopete version. I'd disagree about the trickery and incorrect package name charges. Its correct name according to convention is kdenetwork3-XXX. The problem here is of the Kopete dev team's making (which I belong to). Kopete has been tied to the KDE release cycle since KDE 3.2, it's only for this 0.12 release that we have broken this link. I'm looking for a solution that will allow us to upgrade from 3.5.x to kopete-0.12 to <future location of kopete> 4.0, 3.6, etc. I'll get back to you when I find it. Will Stephenson

2 1

kdenetwork3-InstantMessaging vs kopete
by Pascal Bleser 19 Dec '05

19 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi yall I'd like to discuss the fact that the kopete package is called "kdenetwork3-InstantMessaging". After doing some research (and with some help), I know that the decision to name that package this way comes from SUSE (and not from the KDE team). I think it's not a good idea to name kopete that way, although the name isn't the issue, but the version number. In fact, it's e.g. kdenetwork3-InstantMessaging-3.5.0, but in reality it's some kopete version (e.g. 0.11.x) This raises a number of issues, where the most important is: now there's going to be a kopete 0.12.0 very soon... how are we supposed to name/number the package ? - - we can't name it kdenetwork3-InstantMessaging-3.5.1, because when KDE 3.5.1 will be released (possibly with a different kopete version but, most importantly, built against another version of kdelibs3) it will collide - - we can't name it kopete either (with a Conflicts:kdenetwork3-InstantMessaging) because end users won't see that as an upgrade of kdenetwork3-InstantMessaging - - we /could/ use the release to provide an upgrade, but that's a) misusing the release tag for what is actually a different version number b) a pain to maintain, because maybe SUSE releases an update kdenetwork3-InstantMessaging (with kopete 0.11.x) and then we'd have to re-package it with a higher release number than SUSE c) just an evil workaround and trickery whereas the issue should be solved by giving the package its correct name in the first place Could someone from SUSE please provide some feedback on this ? Stephan ? AJ ? Would it be possible to rename kdenetwork3-InstantMessaging-3.5.0 to kopete-0.11.x ? To me, it really doesn't make any sense to call it "kdenetwork3-InstantMessaging", kopete is not even tightly bound to a specific KDE release, it just creates issues for community packagers who want to provide packages of the latest kopete version. thanks cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpdLer3NMWliFcXcRAnAFAJ4g4vsjTgMerV1Uf4gglUPpxuSZ+gCfQJ/4 IYoI5gmgEpeR07QQY5W6m+8= =FOsv -----END PGP SIGNATURE-----

3 6

ghostscript packages
by Volker Kuhlmann 18 Dec '05

18 Dec '05

The x11/x11alpha device in ghostscript 8.15 (SUSE 10.0), and used by e.g. gv and kghostview, only produces utter rubbish as output and is therefore useless. ghostscript 8.53 is noticably better, but still not as good as 7.07.1. Question: has anyone tried to make packages for gs 8.53 and/or 7.07 which install in an alternative location, so they can be installed in addition to the system packages? I have tried with 7.07 as from Suse 9.2 (removing omni, hpijs, cdj880 as that stuff simply doesn't compile), but the packaging needs more work (interaction with cups - should prob disable that, fonts - can be shared with 8.15). Thanks, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.

2 2

Python packages and noarch
by Pascal Bleser 18 Dec '05

18 Dec '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I'm getting productive with my new x86_64 box and noticed something... let's say "annoying" :) I have quite some python module packages around and when they only include ".py" files (and not ".so" files), I mark them as BuildArch:noarch Now I noticed while installing a python package (noarch) that it isn't found by python. The reason: as it's noarch, it's being installed in /usr/lib/python2.4 (having built it on an x86 box, and not an x86_64). But python only looks up its modules in /usr/lib64/python2.4 Does this mean that *all* python packages must be arch-specific, even when they're not (because they only include Python code and not native shared libs), just to have that path set correctly ? (that's a least what it looks like) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpUyXr3NMWliFcXcRAp1BAJ9DtArUzz7Gf6k0Esr0DZrTzOhFwACfVAew 8ScMB+ffubF7IVVfwfyCQCQ= =RKkv -----END PGP SIGNATURE-----

2 1