On Sunday, May 10, 2020 at 12:36:58 PM UTC-7, Greg Troxel wrote:
>
> Vince Skahan <[email protected] <javascript:>> writes:
>
> > A good example is trying to do a dpkg or rpm that requires
> python3-cheetah
> > when your distro does not 'have' such a package. If you install cheetah
> > with pip as a second way to get it onto the system, if your package
> isn't
> > smart enough to support that, a package installation will fail and you
> > would have to use a --force or a --ignore-dependencies (or the like)
> switch
> > to force the package to install. Those options cause risk too, and a
> > non-linux person won't understand the risks nor how to deal with
> adventures
> > if they pop up.
>
> That sounds like a broken packaging system. In order to have weewx, it
> first has to have all the dependencies. People doing package
> maintenance deal with this as part of package creation.
>
>
>
It's not a broken packaging system, it's operating system differences and
trying to use one package to handle all os variants+versions with one
package. I've battled this for 15+ years in $work.
A python app packaged in rpm format would run on centos 5, 6, 7, 8 just
fine but some versions have corequisite library xyz and some don't. That
would mean the rpm works in some os+version combinations, but not all.
Confusing to the user when a rpm refuses to install and the os gives the
user a cryptic not-helpful message.
Same with dpkg installations. We see differences between ubuntu and debian
variants, versions of each os variant, and other dpkg-compatible operating
systems (Mint etc.)
I can think of three ways out of this os+variation problem:
- (1) smarter packages - you can certainly build rpms with a lot of
conditional logic based on os+version combinations. I dunno about dpkg.
Downside here is you're always catching up to things people find as the os
'standard' moves due to the upstream vendor
- (2) stop using the os's python modules. Bundle at least the add-on
modules weewx needs 'with' weewx core, located under the weewx tree
someplace. Fix up PYTHONPATH or the like as needed.
- (3) build a zillion packages and host a zillion repos. Have people
pick the right repo for their os variant. See https://rpms.remirepo.net
for one good example. Scroll down in the page for all the os
versions+variants he supports. Amazing.
Option-1 is too much catchup, and too painful
Option-2 is how big apps like splunk and puppet do it. They bundle the
interpreter+libs they need under their tree. If you think about it, it's
also how RHEL chose to work the python issue for RHEL-8. They don't use
the /usr/bin/python3 stuff. They have their own internally-used-only path
with the things 'they' need.
Option-3 is how you'd do it in a CI/CD/autotest world. The Remi repos are
a great example of this. It's certainly technically possible to build an
infinite number of os+version package variants via Docker and Github hooks
if we wanted to go that path.
FWIW - I lean to option-2 - just package what weewx needs 'under' the weewx
tree the dpkg or rpm installs. Don't use the os python libs at all.
The downside of option-2 is what would we do if a security vulnerability
appears in one debian-ish variant (only) of configobj, as a hypothetical
example. Would you rerelease weewx for just that os+version (perhaps, bump
a revision number on the same weewx-4.0.0 base name so yum update sees
something needing updating) ? All those what-if's need to be thought of.
Anyway - personally I really like option-2 as it gets us out of the "did my
os provide the expected package for python3-whatever" problem.
--
You received this message because you are subscribed to the Google Groups
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-development/087f1bf9-0d44-44c4-989e-ad1e10f59b10%40googlegroups.com.
