UDS Mountain View: Call for Topics

[Sebastian Heinlein]

Am Sonntag, den 15.10.2006, 22:36 +0200 schrieb Dennis Kaarsemaker:
> On vr, 2006-10-13 at 16:10 -0700, Matt Zimmerman wrote:
> 
> > If you have an idea, it is wise to discuss it on
> > ubuntu-devel at lists.ubuntu.com to get feedback from others before proposing
> > it.  Topics which have been discussed and rejected before, or which aren't
> > within the scope of the meeting or the project will not be accepted.
> 
> I read this part only after adding a spec to the agenda, but I'd still
> like some feedback about https://wiki.ubuntu.com/SoftwareChannelSpec
> before uds-mtv. So please comment :)

Short summary of my comment:

I think that the wiki page should be turned into a ISV howto and not a
feature spec.


At first I am very unhappy about introducing a new terminology. Apt uses
sources so we should stay with source and not use channels. A repository
is used as a source. The term channel was introduced some time ago, but
I am unsure if this was done based on a detailed rationale. The term is
not used anymore in edgy's software-properties, since the user interface
provides a less technical abstraction.

I think that we already addressed most of the issues of this spec with
edgy. What is already possible today:

* The software-channel as package concept already exists: take a look at
app-install-commercial (details at the ed of this e-mail)

* Double click on a sources.list and you will be asked if you want to
add the repositories as sources. Even drag and drop to the third party
repositories list is supported.

* The sources.list is abstracted and the user doesn't need to edit
config files using a text editor to disable/enable a component.

* There are .info files that allow to define parent/child repositories
and mirrors. But they are currently only fully used for distribution own
repositories.

* If you add a comment to the end of an apt-line, only the comment will
appear in the third party repo list of software-properties. Moreover the
software-properties show disabled third party repositories. So it is
easy to enable/disable them.

Problems and objections:

* Why should it be easier to disable a software channel? Not allowing
the user to disable a component of a repository doesn't seem to be a
benefit. I don't see a connection between software channel and the user
interface.

* 'The clumsy "show unsupported/commercial"' provides a vital feature:
it allows the user to browse and therefor install applications that are
not included in the currently enabled repositories. The idea is to
abstract the repository to the meanings of installing software from it.
E.g.  universe => installing software that don't come with full
technical support by Canonical, multiverse => installing software that
you cannot use freely

* Why should only main and restricted be enabled by default?

* Graphical apt-key fronted == software-properties. Furthermore you
cannot use a graphical frontend in the postinst procedure. Perhaps a
debconf question, if you want to install the key, would be a better
solution.

* About untrusted repositories: You should not install packages from
untrusted sources at all. If you don't know what a packages contains and
don't trust its provider, you should not use it at all.

* Finally there is also Jerry Haltom's spec:
https://features.launchpad.net/distros/ubuntu/+spec/third-party-apt


So currently an ISV could create the following package:

/usr/share/app-install/channels/edgy-vendor.list:
deb http://mainserver/ubuntu edgy main # Software that you will love

/usr/share/app-data/desktop/myapp.desktop

/usr/share/app-install/icons/myapp.png

/usr/share/app-install/channels/edgy-vendor.eula

Cheers,

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20061018/f0d4bbe7/attachment.pgp