[Pkg-sugar-devel] Why track activity version numbers?

Fri Apr 21 11:53:14 UTC 2017

Quoting Tony Anderson (2017-04-21 09:12:29)
> My questions are from a Sugar perspective.

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.

> 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.

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.

> Normally, a school does not change software levels during a school 
> year. If the software gets corrupted, it is re-installed.

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.

> 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.

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

> 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.

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.

> 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).

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sugar-devel/attachments/20170421/3364a0d4/attachment.sig>