On 03/22/2018 07:55 AM, Ralf Corsepius wrote:
On 03/22/2018 11:32 AM, Matěj Cepl wrote:
On 2018-03-22, 06:51 GMT, Till Maas wrote:
I orphaned josm
(https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsrc.fedoraproject.org%2Frpms%2Fjosm&data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C5a0ddf82ead04ced634e08d58fec590f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636573167871918432&sdata=kw8f8UlpOLMGfl114wNs9CJ%2FiMgo%2FXSbeMLZG%2FmHUaE%3D&reserved=0),
the
java openstreetmap editor on request by the original
maintainer. Please adopt it. It needs to be updated regularly
to follow the current openstreetmap guidelines, currently it
is outdated (also in EPEL).
My experience with JOSM is that this is probably one of the
programs which are better not to be packaged (other example: vim
plugins). Java Web Start on
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjosm.openstreetmap.de%2Fdownload%2Fjosm.jnlp&data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C5a0ddf82ead04ced634e08d58fec590f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636573167871918432&sdata=G6r7z1UwTvlESHt1KRiXYSj6DKv6Q%2BhRhuK9mamhvxc%3D&reserved=0
works just fine
and I don't see the reason why we should bother with packaging
it ourselves.
The reasons for packaging something up as rpm is security and system
integrety/consistency, i.e. not to endanger installations from the
(windowish) mindset of "unpackaged" third party stuff.
What you say, basically means you are questioning and deny the
usefulness of packaging as a whole. The key feature which has made
Linux distros great and superior to Windows.
I fundamentally agree with Ralph, but I also wanted to point out that
the situation is more complicated than it used to be. The executable
content is available a spectrum of ways, from most heavyweight to most
lightweight
1. ELF binaries
2. binary run-time loadable libraries
3. script files for scripting language environments (java programs
could be arguably placed here)
4. scripting language libraries
5. java applets running in the browser
6. javascript running in the browser
Clearly, we want to package 1. and 2., and we aren't going to start
packaging 6; there's a big discussion as to what's the right approach
for 3 and 4 (npm, conda, cargo, etc).
My point is that we have to decide where we put the line; what Ralph is
saying, and I agree, is we want to push it as far down as
practical---but there always be some executable content that doesn't
make sense to be packaged. We just need to decide why we're packaging
and what are the tradeoffs.
One way of looking at it is that packaging provides an assurance that
the software we're running is the software we think you're running, as
opposed to downloading random binaries and scripts from the internet
(curl | /bin/sh). In this way of thinking, software downloaded from
secure (TLS/https) connections to trusted sites could be considered as
good as packaged---we're doing it to javascript so why not java and
other things. The .jnlp file that provides JOSM is essentially an XML
file which starts the java machinery running the OSM-provided java
application--I can see how people could argue that it's no different
from maps.google.com starting a javascript mapping application in your
browser.
Another criterion could be whether the software installs itself on your
system, or is transient, putting the line pretty firmly between 4. and
5. That would push the JOSM into the packaged category. This approach
addresses the bitrot aspect---the fact that unpackaged software has a
tendency to fall behind and end up with bugs and exploits.
I think that we should reflect on such fundamental requirements because
they are relevant to how the modularity and container situation develops.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
