ubiquity migrated to git

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

ubiquity migrated to git

Dimitri John Ledkov
$ git clone lp:ubiquity
$ git push lp:~user/ubiquity

is all you need to know if you already have the git lp: url setup in
your ~/.gitconfig
[url "git+ssh://[hidden email]/"]
        insteadof = lp:

(See https://help.launchpad.net/Code/Git for more details)

lp:ubiquity is owned by ~ubuntu-installer team, and thus access rights
should be same as the bzr branches.

This repository has most of the tags, and currently has three branches:
* xenial
* bionic
* master

I expect master branch to be used for the currently-in-development
release, and branches created on the as-needed basis for SRUs (most
likely just the SRUs). Similar to bzr trunk & series-proposed branches
were used.

Bzr branches are still available from launchpad, simply git is not the
default VCS.

ps. .bzrignore & .bzr-builddeb pre-build hook have not yet been ported
to git, only the history import was done so far.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Ubiquity NG - was Re: ubiquity migrated to git

Mark Shuttleworth-2

Thanks Dimitri for this!

I'd like to start a thread on Ubiquity NG, and this seems like the best
place and time to start :)

First, a trip down memory lane. MDZ and I were shooting the moon on a
Saturday afternoon in my apartment in London when the idea for Ubiquity
formed. A live CD that would let people try out Ubuntu, and then dive
straight into the install, seemed like science fiction but quickly took
shape on a piece of paper that I rather wish I'd kept. MDZ created
Casper (the friendly ghost that most people won't see) and the rest is
history.

Now, 14 years later, we have a few new kinds of magic to draw on, and
perhaps Ubiquity NG could take advantage of them.

First, we have Curtin, which knows how to take a description of a
machine and do-the-right-thing; partitioning, installing, and cleaning
up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
and the new Ubuntu Server installer, Subiquity. It knows how to install
a couple of different flavours of Linux, including Ubuntu and CentOS,
which could be handy. It's probably the best place for us to handle new
kinds of partitioning and root filesystem and network storage.

Second, we have MAAS, which has some very nice HTML interfaces for
configuring network and storage on a machine. All of that lines up with
Curtin, because MAAS uses Curtin to do the actual install. So we have
the beginnings of an HTML5 installer.

Third, we have Electron, which is the HTML5 app framework used by world
class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
are Electron apps.

Fourth, we have snaps, which are just amazingly tasty ways to get the
latest bits in the hands of your community.

Who's game to sketch this further?

Mark


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Simon Quigley-2
Hello Mark,

On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
<snip />

> First, we have Curtin, which knows how to take a description of a
> machine and do-the-right-thing; partitioning, installing, and cleaning
> up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
> and the new Ubuntu Server installer, Subiquity. It knows how to install
> a couple of different flavours of Linux, including Ubuntu and CentOS,
> which could be handy. It's probably the best place for us to handle new
> kinds of partitioning and root filesystem and network storage.
>
> Second, we have MAAS, which has some very nice HTML interfaces for
> configuring network and storage on a machine. All of that lines up with
> Curtin, because MAAS uses Curtin to do the actual install. So we have
> the beginnings of an HTML5 installer.
Would we be able to customize this in a way that's fit for desktop users
rather than server users? A fork might need to happen there.

> Third, we have Electron, which is the HTML5 app framework used by world
> class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
> are Electron apps.

I respectfully disagree that this is the correct approach for a system
installer. With all due respect to these very popular applications,
Electron uses quite a bit of system resources and could be interesting
to get working correctly. If you are absolutely certain that this is the
way to go, I won't argue this point too much, but I believe that you
would have triple the speed (and/or it would use a third of the memory)
by writing a native application rather than an Electron one, and with
proper testing and organization (perhaps by using a compiled language
rather than an interpreted one, etc.), it would be a very welcome speed
jump over the current Ubiquity codebase.

> Fourth, we have snaps, which are just amazingly tasty ways to get the
> latest bits in the hands of your community.

I would also respectfully disagree that this is the correct way to
deliver a desktop system installer. With snaps, while you have the
advantage of one installer across all versions of Ubuntu (and the usual
advantages of such a workflow), it could sacrifice stability, especially
if the snap has to be updated to a new version on boot (think about
systems with no internet access on install time), and with confinement,
it needs to be done just right to get the proper bits to do a full
system install. There is also the issue currently with desktop
integration (so GTK or Qt theming will not work correctly, and a few
other issues that won't make the experience as smooth as can be).

I'm not entirely opposed to the idea of snapping it and delivering it
that way, but the ecosystem and integration has some issues that should
really be worked out before the installer is done this way. Delivering
as a deb does have the advantage of the Stable Release Updates process
for stable releases, which can ensure that proper QA processes are
followed (with bug tracking), and any Ubuntu Core Developer has the
upload access to provide bugfixes (and doesn't have to learn an entirely
new ecosystem to fix a bug in the installer, which is important for
flavors).

Thanks for the thread, Mark!

--
Simon Quigley
[hidden email]
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Didier Roche-3
In reply to this post by Mark Shuttleworth-2
Le 05/05/2018 à 08:15, Mark Shuttleworth a écrit :

> Thanks Dimitri for this!
>
> I'd like to start a thread on Ubiquity NG, and this seems like the best
> place and time to start :)
>
> First, a trip down memory lane. MDZ and I were shooting the moon on a
> Saturday afternoon in my apartment in London when the idea for Ubiquity
> formed. A live CD that would let people try out Ubuntu, and then dive
> straight into the install, seemed like science fiction but quickly took
> shape on a piece of paper that I rather wish I'd kept. MDZ created
> Casper (the friendly ghost that most people won't see) and the rest is
> history.
>
> Now, 14 years later, we have a few new kinds of magic to draw on, and
> perhaps Ubiquity NG could take advantage of them.
>
> First, we have Curtin, which knows how to take a description of a
> machine and do-the-right-thing; partitioning, installing, and cleaning
> up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
> and the new Ubuntu Server installer, Subiquity. It knows how to install
> a couple of different flavours of Linux, including Ubuntu and CentOS,
> which could be handy. It's probably the best place for us to handle new
> kinds of partitioning and root filesystem and network storage.
>
> Second, we have MAAS, which has some very nice HTML interfaces for
> configuring network and storage on a machine. All of that lines up with
> Curtin, because MAAS uses Curtin to do the actual install. So we have
> the beginnings of an HTML5 installer.
>
> Third, we have Electron, which is the HTML5 app framework used by world
> class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
> are Electron apps.
>
> Fourth, we have snaps, which are just amazingly tasty ways to get the
> latest bits in the hands of your community.
>
> Who's game to sketch this further?
>
> Mark
>
>
Hey Mark,

Some of us on the desktop team are volunteering for that task.

I personnally remember when I received those 2 separate live and install
CD from Ubuntu 4.10. I was already praising the number of
simplifications that Ubuntu added in the Debian installer. However, this
was nothing compared the first time I was able to experience ubiquity
and this single live/install CD. I was quite amazed that was even
doable! I still think that even if ubiquity is showing its age, it
doesn't have any equivalent in term of friendliness, ease of use, and
limiting the user interaction to the minimum required, while starting
installing as quickly as possible.

This is one of the reason I'm personally motivated, like others in our
team to give a help here, shaping the next standard of the existing
installer space. Marrying those technologies will need some deep dive
analysis of course, but I'm confident we can get there. Also, it's the
perfect time for starting this effort as it's obviously a multi-cycles
work to shape it with a robust, and strongly tested approach.

Just a warning, as most of the interested people are French, we aren't
sure yet about the need for localization support…</french conspiracy> ;)

Cheers,
Didier


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Mark Shuttleworth-3
On 05/09/2018 08:33 AM, Didier Roche wrote:

> Some of us on the desktop team are volunteering for that task.
>
> I personnally remember when I received those 2 separate live and
> install CD from Ubuntu 4.10. I was already praising the number of
> simplifications that Ubuntu added in the Debian installer. However,
> this was nothing compared the first time I was able to experience
> ubiquity and this single live/install CD. I was quite amazed that was
> even doable! I still think that even if ubiquity is showing its age,
> it doesn't have any equivalent in term of friendliness, ease of use,
> and limiting the user interaction to the minimum required, while
> starting installing as quickly as possible.
>
> This is one of the reason I'm personally motivated, like others in our
> team to give a help here, shaping the next standard of the existing
> installer space. Marrying those technologies will need some deep dive
> analysis of course, but I'm confident we can get there. Also, it's the
> perfect time for starting this effort as it's obviously a multi-cycles
> work to shape it with a robust, and strongly tested approach.
>
> Just a warning, as most of the interested people are French, we aren't
> sure yet about the need for localization support…</french conspiracy> ;)

Quite right, we are all about the freedom to learn a proper language :)

Mark

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Oliver Grawert
In reply to this post by Simon Quigley-2
hi,
Am Dienstag, den 08.05.2018, 18:31 -0500 schrieb Simon Quigley:
> Would we be able to customize this in a way that's fit for desktop
> users
> rather than server users? A fork might need to happen there.

i would assume if we have an HTML installer the code design could be
set up in a properly split way, so that the installer backend itself
and its HTML are separate from the actual frontend ... 

... if the HTML is designed with proper fallbacks in mind you could
perhaps even use lynx, w3m or some random webkit frontend ... 

for GUI frontends i'd then expect that you can easily adjust CSS,
wallpapers and whatnot for distro customization... 

i think the proposal to use HTML here will definitely improve
customizability across the board over ubiquity ... 

ciao
        oli
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Chris MacNaughton-3
In reply to this post by Simon Quigley-2
Hey Mark / Simon,
<snip />
Third, we have Electron, which is the HTML5 app framework used by world
class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
are Electron apps.
I respectfully disagree that this is the correct approach for a system
installer. With all due respect to these very popular applications,
Electron uses quite a bit of system resources and could be interesting
to get working correctly. If you are absolutely certain that this is the
way to go, I won't argue this point too much, but I believe that you
would have triple the speed (and/or it would use a third of the memory)
by writing a native application rather than an Electron one, and with
proper testing and organization (perhaps by using a compiled language
rather than an interpreted one, etc.), it would be a very welcome speed
jump over the current Ubiquity codebase.
As a potential alternative to Electron for cross platform webapps built on web technologies, it might be worth looking into webview (https://github.com/zserge/webview) as an alternative. From some of the things I've been seeing around the web it gives reasonable compatibility with Electron without adding the entire Chromium engine to each application; rather, it uses built in web rendering engines wherever possible.

Chris MacNaughton
[hidden email]
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Enrico Weigelt, metux IT consult-2
In reply to this post by Mark Shuttleworth-2
On 05.05.2018 08:15, Mark Shuttleworth wrote:

Hi folks,

> Third, we have Electron, which is the HTML5 app framework used by world > class app developers. Skype, Spotify and a ton of GREAT apps on
Ubuntu> are Electron apps.
quite frankly: I wouldn't count things Skype to "world class".
It belongs to those applications that I only touch if I ever have to,
and then only in a carefully restricted container.

I've tried to build a bunch of electron apps - none of them worked,
(except the trivial hello-world) lots of ugly breaks deep down in the
long dependency chain. I wonder whether anybody ever seriously tested
this stuff before releasing.

Anyways, the whole nodejs stuff has always been really painful -
especially if some native code is involved. Everything's just
bleeding edge, no long term maintenance ... somewhere deep in these
huge dependency chains, something always breaks. Even worse: it often
starts downloading binaries (that tend to be incompatible w/ the host),
calls the wrong compiler w/ wrong flags, etc, etc, etc.

Exactly the kind of stuff that I really can't have on production
systems.

A reasonable approach would require rewriting npm in a way that it
takes modules from the system, helps in automatic debianization, so
we can run everything though the usual deb toolchain and maintainers
can easily patch whenever necessary. Certainly possible, but *a lot*
of work to do, before we reach a reasonable stable state.


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[hidden email] -- +49-151-27565287

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Bryan Quigley-2
In reply to this post by Simon Quigley-2


On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <[hidden email]> wrote:
Hello Mark,

On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
<snip />
> First, we have Curtin, which knows how to take a description of a
> machine and do-the-right-thing; partitioning, installing, and cleaning
> up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
> and the new Ubuntu Server installer, Subiquity. It knows how to install
> a couple of different flavours of Linux, including Ubuntu and CentOS,
> which could be handy. It's probably the best place for us to handle new
> kinds of partitioning and root filesystem and network storage.
>
> Second, we have MAAS, which has some very nice HTML interfaces for
> configuring network and storage on a machine. All of that lines up with
> Curtin, because MAAS uses Curtin to do the actual install. So we have
> the beginnings of an HTML5 installer.

Would we be able to customize this in a way that's fit for desktop users
rather than server users? A fork might need to happen there.

There are no technical reasons why MAAS/Curtin can't be used for desktop installs.
I'm not sure how much sense it makes to reuse the MAAS UI bits though..  We only ask for network bits if you are not connected to a wireless network.

I'd love if we at least move to subiquity/curtin because that means we have to
publish desktop MAAS images which has been something I've been pushing for a while now [1].
This would push us in the direction of "one" best practice way to install Ubuntu on almost everything.

It may even be possible with subiquity to have a text based fallback on a normal live image.  If possible
this might allow an Alternate style install (like Lubuntu has) for all flavors for free.
 

> Third, we have Electron, which is the HTML5 app framework used by world
> class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
> are Electron apps.

I respectfully disagree that this is the correct approach for a system
installer. With all due respect to these very popular applications,
Electron uses quite a bit of system resources and could be interesting
to get working correctly. If you are absolutely certain that this is the
way to go, I won't argue this point too much, but I believe that you
would have triple the speed (and/or it would use a third of the memory)
by writing a native application rather than an Electron one, and with
proper testing and organization (perhaps by using a compiled language
rather than an interpreted one, etc.), it would be a very welcome speed
jump over the current Ubiquity codebase.

Additionally, we'd have to bring Chromium up to the requirements (snappy edition) for Main. (which I wouldn't mind, but doesn't make sense just for this)

Kind regards,
Bryan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Neal Gompa
On Thu, May 10, 2018 at 4:29 AM Bryan Quigley <[hidden email]>
wrote:



> On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <[hidden email]> wrote:

>> Hello Mark,

>> On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
>> <snip />
>> > First, we have Curtin, which knows how to take a description of a
>> > machine and do-the-right-thing; partitioning, installing, and cleaning
>> > up. Curtin is neat and efficient, super-fast, and it's used by both
MAAS
>> > and the new Ubuntu Server installer, Subiquity. It knows how to install
>> > a couple of different flavours of Linux, including Ubuntu and CentOS,
>> > which could be handy. It's probably the best place for us to handle new
>> > kinds of partitioning and root filesystem and network storage.
>> >
>> > Second, we have MAAS, which has some very nice HTML interfaces for
>> > configuring network and storage on a machine. All of that lines up with
>> > Curtin, because MAAS uses Curtin to do the actual install. So we have
>> > the beginnings of an HTML5 installer.

>> Would we be able to customize this in a way that's fit for desktop users
>> rather than server users? A fork might need to happen there.


> There are no technical reasons why MAAS/Curtin can't be used for desktop
installs.
> I'm not sure how much sense it makes to reuse the MAAS UI bits though..
We only ask for network bits if you are not connected to a wireless network.

> I'd love if we at least move to subiquity/curtin because that means we
have to
> publish desktop MAAS images which has been something I've been pushing
for a while now [1].
> This would push us in the direction of "one" best practice way to install
Ubuntu on almost everything.

> It may even be possible with subiquity to have a text based fallback on a
normal live image.  If possible
> this might allow an Alternate style install (like Lubuntu has) for all
flavors for free.



>> > Third, we have Electron, which is the HTML5 app framework used by world
>> > class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
>> > are Electron apps.

>> I respectfully disagree that this is the correct approach for a system
>> installer. With all due respect to these very popular applications,
>> Electron uses quite a bit of system resources and could be interesting
>> to get working correctly. If you are absolutely certain that this is the
>> way to go, I won't argue this point too much, but I believe that you
>> would have triple the speed (and/or it would use a third of the memory)
>> by writing a native application rather than an Electron one, and with
>> proper testing and organization (perhaps by using a compiled language
>> rather than an interpreted one, etc.), it would be a very welcome speed
>> jump over the current Ubiquity codebase.


> Additionally, we'd have to bring Chromium up to the requirements (snappy
edition) for Main. (which I wouldn't mind, but doesn't make sense just for
this)


The Korora guys were considering adding a web-based desktop frontend to
Anaconda a few years ago, and developed the Lens framework[1][2] for that
purpose. It's a much more lightweight alternative that also supports some
level of integration for Qt and GTK+ based desktop environments.

[1]:
https://kororaproject.org/about/news/lens-an-alernative-to-desktop-agnostic-uis
[2]: https://github.com/kororaproject/kp-lens

--
真実はいつも一つ!/ Always, there's only one truth!

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Aaron Honeycutt-2
In reply to this post by Bryan Quigley-2
Is there a reason why we can't use Calamares or the new Elementary/Pop!_OS installer for the desktop and leave MASS/Curtin for the server and such?

On Thu, May 10, 2018 at 5:29 AM Bryan Quigley <[hidden email]> wrote:


On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <[hidden email]> wrote:
Hello Mark,

On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
<snip />
> First, we have Curtin, which knows how to take a description of a
> machine and do-the-right-thing; partitioning, installing, and cleaning
> up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
> and the new Ubuntu Server installer, Subiquity. It knows how to install
> a couple of different flavours of Linux, including Ubuntu and CentOS,
> which could be handy. It's probably the best place for us to handle new
> kinds of partitioning and root filesystem and network storage.
>
> Second, we have MAAS, which has some very nice HTML interfaces for
> configuring network and storage on a machine. All of that lines up with
> Curtin, because MAAS uses Curtin to do the actual install. So we have
> the beginnings of an HTML5 installer.

Would we be able to customize this in a way that's fit for desktop users
rather than server users? A fork might need to happen there.

There are no technical reasons why MAAS/Curtin can't be used for desktop installs.
I'm not sure how much sense it makes to reuse the MAAS UI bits though..  We only ask for network bits if you are not connected to a wireless network.

I'd love if we at least move to subiquity/curtin because that means we have to
publish desktop MAAS images which has been something I've been pushing for a while now [1].
This would push us in the direction of "one" best practice way to install Ubuntu on almost everything.

It may even be possible with subiquity to have a text based fallback on a normal live image.  If possible
this might allow an Alternate style install (like Lubuntu has) for all flavors for free.
 

> Third, we have Electron, which is the HTML5 app framework used by world
> class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
> are Electron apps.

I respectfully disagree that this is the correct approach for a system
installer. With all due respect to these very popular applications,
Electron uses quite a bit of system resources and could be interesting
to get working correctly. If you are absolutely certain that this is the
way to go, I won't argue this point too much, but I believe that you
would have triple the speed (and/or it would use a third of the memory)
by writing a native application rather than an Electron one, and with
proper testing and organization (perhaps by using a compiled language
rather than an interpreted one, etc.), it would be a very welcome speed
jump over the current Ubiquity codebase.

Additionally, we'd have to bring Chromium up to the requirements (snappy edition) for Main. (which I wouldn't mind, but doesn't make sense just for this)

Kind regards,
Bryan
--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Enrico Weigelt, metux IT consult-2
In reply to this post by Bryan Quigley-2
On 09.05.2018 22:29, Bryan Quigley wrote:

> Additionally, we'd have to bring Chromium up to the requirements (snappy
> edition) for Main. (which I wouldn't mind, but doesn't make sense just
> for this)

Maybe use Servo or Surf instead ?


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[hidden email] -- +49-151-27565287

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ubiquity NG - was Re: ubiquity migrated to git

Luke Faraone-2
In reply to this post by Enrico Weigelt, metux IT consult-2
On Thu, 10 May 2018 at 11:30, Enrico Weigelt, metux IT consult <
[hidden email]> wrote:

> On 05.05.2018 08:15, Mark Shuttleworth wrote:

> Hi folks,

> > Third, we have Electron, which is the HTML5 app framework used by world
> class app developers. Skype, Spotify and a ton of GREAT apps on
> Ubuntu> are Electron apps.
> […]

> Anyways, the whole nodejs stuff has always been really painful -
> especially if some native code is involved. Everything's just
> bleeding edge, no long term maintenance ... somewhere deep in these
> huge dependency chains, something always breaks. Even worse: it often
> starts downloading binaries (that tend to be incompatible w/ the host),
> calls the wrong compiler w/ wrong flags, etc, etc, etc.

> Exactly the kind of stuff that I really can't have on production
> systems.

> A reasonable approach would require rewriting npm in a way that it
> takes modules from the system, helps in automatic debianization, so
> we can run everything though the usual deb toolchain and maintainers
> can easily patch whenever necessary. Certainly possible, but *a lot*
> of work to do, before we reach a reasonable stable state.

Technically, this already exists, and there are a large number of node-*
packages in Debian, at the very least:
https://wiki.debian.org/Javascript/Nodejs/Npm2Deb

I agree with your other points — supporting anything in the NodeJS
ecosystem in LTS releases is going to be incredibly challenging, and I
worry that something like Electron is too much complexity for the benefit,
as long as we're sticking to our packaging policies.

--
Luke Faraone;; Debian & Ubuntu Developer; Sugar Labs; MIT SIPB
lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello
PGP fprint: 8C82 3DED 10AA 8041 639E  1210 5ACE 8D6E 0C14 A470

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel