Re: josm orphaned, or why are we packaging

Przemek Klosowski <przemek.klosowski@xxxxxxxx> · Thu, 22 Mar 2018 13:49:27 -0400



    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="">),
          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="">
        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

    
      ELF binaries
      binary run-time loadable libraries 
      script files for scripting language environments (java
        programs could be arguably placed here)

      
      scripting language libraries 

      
      java applets running in the browser
      _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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx