Hi,
Yesterday I learned something new and I think, so will you now:
most of us (including me) did package renames the wrong way and
the documentation in the wiki on it is unfortunately not very clear.
So let me get this straight and I hope everyone will use it correctly
from now on:
oldpac.spec:
Name: oldpac
Version: 1.0
baselibs.conf:
oldpac
You want to rename it to newpac on update, what do you have to do?
newpac.spec:
Name: newpac
Version: 1.1
Provides: oldpac <= 1.0
Obsoletes: oldpac <= 1.0
baselibs.conf:
newpac
obsoletes "oldpac-<targettype> <= 1.0"
provides "oldpac-<targettype> <= 1.0"
That's it - please always use <= with the latest version oldpac had,
everything else is most likely wrong. And don't forget about the baselibs.
Greetings, Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
there is some fallout from the rpmlint 0.83 (new upstream release) upgrade in
Factory, where a broken change caused a bootstrap issue and consequently all
packges failed, and even a fixed package didn't build anymore.
Please ignore rpmlint related failures today, everything should be back to
normal tomorrow.
Greetings,
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello everyone,
both Python 2.6 and Python 3.0 final releases are scheduled on Sep 04
[1], and they are both going into openSUSE 11.1
During this week i'm going to submit Python 2.6 to BETA (and probably
mirror it to BuildService as well), and prepare a Python 3.0 package in
BuildService, called "python3".
Then i will be away for two weeks, and when i return, i'll start moving
things to STABLE/Factory
Gentle introduction
- ---
Python 2.6 is planned to be the last release of 2.x series. It should be
mostly backwards compatible to 2.5, and also forward compatible to 3.0.
Python 3.0, dubbed Py3k, will be massively *backwards incompatible*, and
most of existing python code will not work in it. To ease the
transition, there are two things:
- - "2to3" converter script [2], which can translate existing 2.x
compatible code to 3.0. The script is part of Python 2.6 release.
- - Python 2.6's __future__ imports and Py3k warnings mode, which, simply
put, turn 2.6 interpreter into 3.0-compatible transition device.
Quoting PEP-361 ([1]):
>> Python 2.6 is not only the next advancement in the Python 2
>> series, it is also a transitional release, helping developers
>> begin to prepare their code for Python 3.0. As such, many
>> features are being backported from Python 3.0 to 2.6. Thus, it
>> makes sense to release both versions in at the same time. The
>> precedence for this was set with the Python 1.6 and 2.0 release.
Python 2.x series is slowly going to be deprecated in favor of 3.x
series - but it seems now that it's a matter of years, not months.
Inclusion proposal
- ---
1. Python 2.6:
Nothing much to say here, that should be a simple version increase. No
major changes like 2.5's Py_ssize_t mayhem are planned.
/usr/bin/python will be a symlink to /usr/bin/python2.6, and in addition
/usr/bin/python2 will also be a symlink to python2.6.
2. Python 3.0:
This is basically a "new product" which is going to be installed
alongside and not colliding with regular 2.x python.
Its binary will be /usr/bin/python3.0, and a symlink /usr/bin/python3.
No packages depending on python 2.x should be harmed by having py3k
present. Also, there probably won't be any packages depending on py3k yet.
regards,
m.
[1] http://www.python.org/dev/peps/pep-0361/
[2] http://svn.python.org/view/sandbox/trunk/2to3/
- --
(if you have any comments, please CC me in the reply, otherwise my
replies will break threads. that is a bug in my way of using the
mailinglist, which is not yet fixed)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkhilvoACgkQjBrWA+AvBr9TOwCfVZuYUlMYHn4Zkg0rarka/5O7
Z40An0Peh/qXFldNFxkJurqYP3UU5xoC
=deZV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
as already mentioned yesterday, I reorganized the openldap2 packages
according the the shared library policy. For that I just submitted new
packages to autobuild. The openldap client libraries (libldap and
liblber) have been moved to the libldap-2_4-2 Package. The
openldap2-client package now only contains the command line tools
(ldapsearch and so on) and the related manpages.
Normally you should not notice anything of the change as the
dependencies on the libraries are generated automatically and the name
of the development package (openldap2-devel) that should be used in
BuildRequires has not been changed.
If you are maintaining a package that has a direct dependency on
openldap2-client you should probably check that package if that
dependency is really needed.
--
regards,
Ralf
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
I do not know how to package java classes.
Programms are stored in /usr/share/java,
but where do I store classes used by these (in .jar format) and what about
support libraries.
Especially I talk about the packages "BT747" and "rxtx-java" in
Application:Geo project of BuildService.
I have a working solution, but I'm pretty sure the current solution is not
correct.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I am currently trying to split one of my packages (openldap2) according
to the shared library packaging policy and I am wondering what the
correct package name would be. The SONAME of the main library
is: "libldap-2.4.so.2". According to the policy that would make a
package name of: "libldap-2.4-2". But AFAIK we have some rule that dots
in the package name are not allowed, is that correct? If yes, what
would be the correct package name?
BTW, to keep the required changes in other packages as minimal as
possible I will not rename the main development package. That will
still be called openldap2-devel. Renaming that would require changes in
tons of other packages' Buildrequires.
--
regards,
Ralf
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Tuesday 17 June 2008 16:27:35 Ludwig Nussel wrote:
> While moving my files to a new workstation I stumbled across
> /srv/www. The directory contains a mix of self written stuff and
> distro packages. So I needed to take care to only copy my own files.
> I'd assume that someone who actually uses /srv/www in production and
> cared about the content would have a similar problem when creating
> backups. The apache packages allows other packages to simply
> drop a config file into /etc/apache2/conf.d and install e.g. a
> custom directory alias this way. So files that need to be accessible
> via http://somehost/foo do not actually need to be stored at
> /srv/www/htdocs/foo but can reside in e.g. /usr/share/foo. So I
> wonder what's best practice for packages. Dump stuff into /srv/www
> or use aliases in the web server config? FHS is quite unspecific wrt
> use of /srv [1].
I have also thought about this when creating my trac packages. I have decided
not to put the trac files below /srv/www/htdocs and instead to provide a conf
file. But I am in doubt if this is the right thing. For my ldap-account-
manager packages on Packman (which should be moved into the BS), I have
decided to install below /srv/www/htdocs without being sure to do the right
thing, too. I had a look on other packages. The medaiwiki packages for example
are installed below /srv/www/htdocs.
One thing I discovered that might infer with an out of /srv/www/htdocs
installation is apparmor. It seems that it expects that all web pages are
installed below /srv/www/htdocs. For packages installed elsewhere it's rules
must be modified.
Cheers
herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
While moving my files to a new workstation I stumbled across
/srv/www. The directory contains a mix of self written stuff and
distro packages. So I needed to take care to only copy my own files.
I'd assume that someone who actually uses /srv/www in production and
cared about the content would have a similar problem when creating
backups. The apache packages allows other packages to simply
drop a config file into /etc/apache2/conf.d and install e.g. a
custom directory alias this way. So files that need to be accessible
via http://somehost/foo do not actually need to be stored at
/srv/www/htdocs/foo but can reside in e.g. /usr/share/foo. So I
wonder what's best practice for packages. Dump stuff into /srv/www
or use aliases in the web server config? FHS is quite unspecific wrt
use of /srv [1].
cu
Ludwig
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSY…
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello again,
i need maven to build a project i would like to package. the maven package
seems to be kind of abandoned. There seem to be no official package
available, when checking with packages search.
Which package does work? Anyone taking care of this still? Are there any other
options building maven packages?
Cheers,
Denny
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org