>The OS dependency management is really not what I'm trying to be
>illusttrative of here. I'm trying to show that deploying a single rpm of
>all your dependencies is problematic compared to deploying with an rpm for
>each of your dependencies. This is not a comparison of system package
>managers vs virtualenvs.
You claim it is problematic. I see no attempt at proving that. But see below.
>I work with rpm distros but the basics are the same. I'm going to write
>down what I would do here based on the needs of my system administrators.
>However, if your environment is not as strict, there's shortcuts that can be
>taken in various places. I can talk about that a little as well.
>
>Let's say that I'm developing for RHEL5 and the SQLAlchemy version there is
>sqlalchemy-0.3 (in fact, that version comes from the EPEL repository but the
>difference in policy there is minimal). Now the hot new app that I'm
>developing is going to make use of features in SQLAlchemy-0.6 so what am
>I going to do?
>
>1) get the source of that package:
> git clone git://pkgs.fedoraproject.org/python-sqlalchemy
>
>2) Update the package to build SQLAlchemy 0.6 instead. In this case, I am
>even lucky enough that the Fedora version of the package (which is
>SQLAlchemy-0.6) is easily comparable to the EPEL-5 version so I can simply
>merge many of the changes from the Fedora version to the EPEL-5 version.
>
>3) Modify the spec to build a parallel installable version instead. In the
>case of SQLAlchemy, the recipe would look something like this:
>
> - Name: python-sqlalchemy
> + Name: python-sqlalchemy0.6
> %build
> - CFLAGS="%{optflags}" %{__python} setup.py --with-cextensions build
> + CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py--with-cextensions bdist_egg
>
> %install
> - %{__python} setup.py --with-cextensions install --skip-build --root
> %{buildroot}
> + easy_install -m --prefix %{buildroot}%{_usr} dist/*.egg
>
>4) Build the package with something like::
> rpmbuild -ba python-sqlalchemy0.6.spec
>
> If I needed to build for RHEL5 but I wasn't on RHEL5, I'd get a free
> account that can use the Fedora BuildSystem for scratch builds and use
> that::
>
> koji build --scratch dist-5E-epel python-sqlalchemy0.6-0.6.1-1.src.rpm
>
>5) Here's one of hte points where shortcuts can be taken. I personally
>would then get this package into EPEL so that others could benefit from
>having this package available. But if you didn't want to do that and your
>site policies allow it, you can also create a private repository where you
>can host the package and pull it in via the system package managers.
>
>> - manage to install it without provoking a conflict with the system's
>> version
>
>In either case, once Step 5 above is complete, installation is:
>
>yum install -y python-sqlalchemy0.6
>
>There will be no conflicts because of the way we installed took care to
>use eggs to install in parallel.
This is the interesting bit. You say they are installed in parallel. How so
exactly? And how do I determine which version I get if I do
$ python
>>> import sqlalchemy
Especially, if I'm going to deploy/develop code for both respective versions?
That is the key. If you have an actual working solution for that, I'm all fine
with using OS packages for deployment, including even the splitting up into
several packages - because then there is a real benefit to meet other apps
dependencies.
>With this setup, the original python-sqlalchemy package continues to be
>under distro control, getting the updates that the distro deems necessary.
The original - sure. Yours not, so all the burden of monitoring bugfixes +
updates for 0.6, and thus there is no real benefit except from IT-requirements
of course.
Diez
___________________________________________________________
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
