‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 27, 2020 10:05 PM, DC* <d...@riseup.net> wrote:

> On 2019-04-13 21:47, Steve Dougherty wrote:
>
> > My impulse would be to decide which distros we want to officially
> > support, and provide packages for them. Perhaps Arch, Debian, and
> > Ubuntu? Both installers for Linux applications and compiling Java to
> > native code strike me as odd approaches that go against the grain of
> > usual software installation, and while I'm not opposed to having them
> > as options for distros we don't have packages for, it does seem liable
> > to increase our support load.
> > Providing packages would allow giving upgrades some nice properties as
> > well - instead of having to write upgrade logic ourselves, the package
> > manager can do it. We need only (expose and) add a package repo like
> > the Google Chrome package does by default. A tool to mirror a USK to
> > disk would be useful here; if memory serves I've written up ideas
> > about this in the past.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, April 12, 2019 4:31 PM, Arne Babenhauserheide
> > arne_...@web.de wrote:
> >
> > > Hi,
> > > With Java 11 Webstart is no longer part of the official
> > > distribution. JNLP files no longer start by default.
> > > What do you think about just providing the jar?
> > > Or should we try whether we can get the installer compiled with Graal?
> > > https://www.graalvm.org/docs/getting-started/#native-images
> > > Best wishes,
> > > Arne
> > >
> > > Unpolitisch sein
> > > heißt politisch sein
> > > ohne es zu merken
>
> What abouthttps://github.com/freenet/debian? With a Debian package you
> cover all Debian-based distros, including Ubuntu and derivatives, adding
> CentOS/Fedora you cover most OSes. I'm not taking into account MacOS or
> Windows.
>
> What needs to be done to move it forward?
>
> Best regards,

I can't speak for Arne but as far as I'm aware the things I mentioned
in my quoted message still apply: we'd need to write a way for the
package to update itself over Freenet. (And for the release scripts to
support building and releasing the package, but that's probably the
easier part of the problem.)

If we write a plugin that watches a USK and writes the contents of the
latest edition to disk, then the package can set the package manager
(so, apt, in this case) to watch that directory for updates. At least
if I were still release manager I'd want it to be enabled and
configured by default when Freenet is installed via this package,
possibly also shipping with default apt-source content if apt yells
when pointed at an empty directory. (But as long as it doesn't error
out, it'd be acceptable not to do this.)

Reply via email to