<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi, Jonas<br>
    <br>
    Thanks for the information about how to install the debian
    'sucrose'. I need to give that a try.<br>
    <br>
    Consider this example:<br>
    <br>
    <pre wrap="">  author: Sugar coders (and GNU coders, Linux coders, etc.)
  publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
  maintainer: James Cameron (and Redhat maintainers, etc.)
  distro: OLPC
  deployer: OLE Nepal team
  admin: Parents, friends and siblings of children at Tundikhel
  user: Children at Tundikhel</pre>
    My guess is that in this case there is no admin. Generally OLE Nepal
    sends a team to the site to do the deployment. <br>
    <br>
    James Cameron describes Sugar on the XO as the OLPC OS. These are
    released by him on <a class="moz-txt-link-abbreviated" href="http://www.laptop.org">www.laptop.org</a>. The current OLPC OS is 13.2.8.
    Generally, there is no maintenance. The changes come in new
    releases. Fortunately, the system is mature enough that there are no
    critical bugs that prevent use of the system.<br>
    Also, in most deployments such as those by OLE Nepal, there is no
    internet access so many security concerns are moot.<br>
    <br>
    So the above should probably be:<br>
    <br>
    author: members of the Sugar and open source community <br>
    publisher: <a class="moz-txt-link-abbreviated" href="http://www.laptop.org">www.laptop.org</a> (James Cameron)<br>
    maintainer: none in the sense you describe (note activities are
    independent of the system and are released to ASLO asynchronously).<br>
    distro: de facto <a class="moz-txt-link-abbreviated" href="http://www.laptop.org">www.laptop.org</a> (OLPC) but should be Sugar Labs
    (debian, Ubuntu, Raspbian, etc.)<br>
    deployer: OLE Nepal team <br>
    user: children and teachers<br>
    <br>
    My real concern is that the Sugar desktop as installed have an
    identifiable version number (in Sugar it is shown in 'About My
    Computer' in 'MySettings').<br>
    Version 0.110 of Sugar should be the same in all distros of Sugar.
    The name sucrose is confusing and appears for historical reasons no
    longer applicable,<br>
    <br>
    <pre wrap="">"I understand how admins and users perceive everything upstream as "an integral part of Sugar"

</pre>
    Actually admins and users accept the installation of Sugar on their
    client as Sugar. Because such a limited number of users have access
    to the internet, ASLO is essentially unknown. <br>
    <br>
    This problem is the Sugar developers. Some see the activities
    incorporated by James Cameron in the OLPC OS versions as integral
    (although that lists varies by Xo model). Even the list of
    'non-erasable' activities is somewhat arbitrary. For example, the
    Chat activity is included but TurtleBlocks is not.<br>
    <br>
    So from a Debian perspective as distro of the Sugar desktop, making
    a canonical version available for even numbered releases of Sugar
    (0.110 -> 0.112) should be the pattern. The desktop should
    include as activities Browse, Write, Chat, Log, Terminal, Record,
    Jukebox, and Image Viewer. Record is a problem because it provides
    the interface to the host's camera and microphone. Other activities
    can be made available by Sugar Labs (as distro) via ASLO for
    installation by users and admins.<br>
    <br>
    Naturally, I am speaking only for myself.<br>
    <br>
    Tony<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 04/21/2017 07:53 PM, Jonas
      Smedegaard wrote:<br>
    </div>
    <blockquote
      cite="mid:149277559478.7651.4858130939386256499@auryn.jones.dk"
      type="cite">
      <pre wrap="">Quoting Tony Anderson (2017-04-21 09:12:29)
</pre>
      <blockquote type="cite">
        <pre wrap="">My questions are from a Sugar perspective.
</pre>
      </blockquote>
      <pre wrap="">
I believe it helps this conversation to distinguish between the 
following perspectives, listed in order of appearance:

 author: Those authoring single components
 publisher: Those releasing canonical versions of components
 maintainer: Those adapting components to fit a system
 distro: Those releasing canonical versions of a system
 deployer: Those mass-installing a system onto many computers
 admin: Those (reinstalling or) adapting an installed system
 user: Those picking a color for their avatar and exploring Sugar

In Debian, we call anyone "above" yourself as "upstream", and anyone 
"below" yourself as downstream.

Here's an example inspired by recent OLPC blog entry:

  author: Sugar coders (and GNU coders, Linux coders, etc.)
  publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
  maintainer: James Cameron (and Redhat maintainers, etc.)
  distro: OLPC
  deployer: OLE Nepal team
  admin: Parents, friends and siblings of children at Tundikhel
  user: Children at Tundikhel


Here's an example taken out of thin air:

  author: Sugar coders (and GNU coders, Linux coders, etc.)
  publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
  maintainer: SoaS hackers (and Redhat maintainers, etc.)
  distro: SoaS
  deployer: none (not mass-installed)
  admin: An enthusiastic math teacher at some US school
  user: Students at some US school


Here's an example depicting a near-future dream:

  author: Sugar coders (and GNU coders, Linux coders, etc.)
  publisher: Sugarlabs via ASLO (and kernel.org, Github, etc.)
  maintainer: James, Sebastian, me (and fellow Debian maintainers)
  distro: Debian
  deployer: Somos Azúcar
  admin: An enthusiastic math teacher at some peruvian school
  user: Students at some peruvian school


Note how from Sugar _author_ and _publisher_ perspective you need not 
care about Debian version numbers at all: The versioning of officially 
released Sugar activities is kept (and extended) by Debian packages.


</pre>
      <blockquote type="cite">
        <pre wrap="">The Browse activity is one of the 'non-erasable' activities which can 
be considered an integral part of Sugar. As I understand pristine - it 
is part of an update-system within Sugar, which in our context i 
consider superfluous.
</pre>
      </blockquote>
      <pre wrap="">
I understand how admins and users perceive everything upstream as "an 
integral part of Sugar
" - but here, discussing integration of Sugar and 
other parts, we *must* distinguish between the various upstream parts.

In Debian context, a (graphical) system consists of kernel, services, 
console tools, GUI desktop and GUI applications.  In this context, Sugar 
is GUI desktop and GUI applications. Yes I know, Sugar *experience* is 
void of office connotations, but technical term is nevertheless desktop.

Systems generally provide separate "user" and "admin" roles, and Sugar 
supports this in what you describe as activities being "non-erasable".

Debian (and most other conventional distribution) further distinguishes 
between distro-controlled and locally controlled "non-erasable" parts: 
Distro-controlled parts gets updated when the distribution is updated.

Some systems (possibly including SoaS) essentially _removes_ the admin 
role: System cannot be updated or customized, only used as-is.

Browse being "non-erasable" is a distro/deployer/admin decision, not a 
Sugar concept.

Browser is an activity like any other - but provides a core features, 
including the ability for the learner to get additional activities 
independent of the admin or other upstreams. Therefore distributions 
commonly includes that activity by default - but with Debian the admin 
can choose to not install Browse - either to deliberately provide the 
learner with a limited Sugar environment, or perhaps to force use some 
_alternative_ web browsing activity added locally.

Browse also - even when non-erasable - is not immutable: The learner can 
choose to install Browse, effectively shadowing the non-erasable one 
with their version of choice (newer or older). When removing that 
$HOME-installed versioned again later, the system-provided version of 
Browse will reappear.


</pre>
      <blockquote type="cite">
        <pre wrap="">Normally, a school does not change software levels during a school 
year. If the software gets corrupted, it is re-installed.
</pre>
      </blockquote>
      <pre wrap="">
Schools will avoid changing _features_, but should apply _bugfixes_. 
Debian distinguishes between feature changes and bugfixes, and provides 
upgrade channels strictly containing the latter - no matter if upstreams 
of Debian have same distinctions.

Feel free to consider such ability to fix bugs as "superfluous". I 
wouldn't recommend that, however.


</pre>
      <blockquote type="cite">
        <pre wrap="">Anyway activities are number incrementally beginning with 1. Some have 
tried to use this system with dates:

such as version 20170412 or with decimal steps 158.2 and so on.
</pre>
      </blockquote>
      <pre wrap="">
Seems you are talking about Sugar _development_ constraints.  They don't 
apply to Debian, and it would not make sense to apply them to Debian.
How to distinguish these?:

 * Browse 45 packaged for Debian 7
 * Browse 45 packaged for Debian 7, with bugfix 4 and 6 applied
 * Browse 45 packaged for Debian 8
 * Browse 45 packaged for Debian 8, with bugfix 4, 5 and 6 applied
 * Browse 45¾ packaged for Debian 9, adapted to Ubuntu Yoghurt


</pre>
      <blockquote type="cite">
        <pre wrap="">So my concern was triggered by two things: an apparent 8 digit version 
number and a blockage because of the pristine system affecting Browse 
update.
</pre>
      </blockquote>
      <pre wrap="">
A Debian stable release do not block updates to Browse (but possibly a 
newer Browse may depend on functionality not available in older Debian)

If your concerns are only Sugar author/publisher/user perspectives, then 
please _totally_ ignore details of Debian versioning and blockage: 
Debian versions and Debian blockage is part of _development_ of Debian.


</pre>
      <blockquote type="cite">
        <pre wrap="">My question for you is, is there a way to install the debian sugar via 
dpkg, for example? Currently I am using the Ubuntu 16.04 version which 
is obsolete and is tied to Ubuntu releases (the current version of 
Sugar 0.110 requires installing Ubuntu 17.04).
</pre>
      </blockquote>
      <pre wrap="">
Yes, the official and supported-by-Deban way to install Debian-packaged 
Sugar onto a _Debian_ system is by use of dpkg.

Normally dpkg is not used directly, however, but triggered by 
APT.  There are many ways to use APT - For single simple tasks I 
recommend the command-line tool "apt", and for more complex interactions 
(like "install those 3 packages, but suppress those 4 recommendations, 
and by the way also include that extra suggestions") I recommend to run 
the command-line tool "aptitude" in fullscreen mode (i.e. start it 
_without_ passing any package names at first).

This command installs Debian-packaged sugar on a _Debian_ system:

  apt install sucrose

If you try any of above on Ubuntu or some other derivative of Debian, 
then feel free to tell on this list that your other system is broken, 
but tell them (not us) to fix it.


 - Jonas

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>