Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.szn.dk!pnx.dk!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Subject: Re: Fresh packaging ideas
Newsgroups: comp.sys.acorn.apps,comp.sys.acorn.programmer
From: Jess Hampshire <jesshampshire@googlemail.com>
X-Editor: EmailEdit 6.00
Date: Mon, 23 Jan 2012 19:43:04 GMT
Message-ID: <6b66355652.jess@itworkshop.invalid>
References: <fUj*KgmXt@news.chiark.greenend.org.uk> <5d11035a-08bc-449d-afe8-78409267623c@k6g2000vbz.googlegroups.com> <fUj*-0xXt@news.chiark.greenend.org.uk> <c4939f92-f104-49a9-b665-579ec159592d@a8g2000vba.googlegroups.com> <ba56ac5352.martin@blueyonder.co.uk> <6e83e65352.Matthew@sinenomine.freeserve.co.uk> <b77e255452.martin@blueyonder.co.uk> <hUj*W8HXt@news.chiark.greenend.org.uk>
Organization: ITWorkshop
User-Agent: Messenger-Pro/6.03 (MsgServe/6.00) (RISC-OS/5.17) NewsHound/v1.50-32
Lines: 70
NNTP-Posting-Host: 92.20.176.158
X-Trace: news.sunsite.dk DXC=?G_QfDPCZQ5dWg;6EL\fA6YSB=nbEKnk;c5[f12P6_M1Mo@OLBVNES:?J[Q:hI>9E=jOgkk0RWXj1O?feD6Eobd1jG]R`f]9k49AXG1a@YCI@0
X-Complaints-To: staff@sunsite.dk
Xref: x330-a1.tempe.blueboxinc.net comp.sys.acorn.apps:2861 comp.sys.acorn.programmer:1405

In message <hUj*W8HXt@news.chiark.greenend.org.uk>
          Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

>> because most applications have not been packaged, and probably never
>> will be.

> I think I see where you're coming from.  We currently have software
> represented by a series of isolated points (Zip archives) on isolated
> servers

<snip 2nd question>

> how to make such Zip archives automatically installable

It seems to me that this should be approached in two ways.

There should be the fall back option, where the packager presents a 
list of packages which it will fetch for the user to install manually. 
This would not need to involve the main underlying package mechanism. 
This would just be a convenience feature, to help find software.

The vast majority of items that would fall into this category would be 
26 bit programs, and they would be far less likely to be of interest 
to a new Pi or BB user (i.e. of interest users who would be used to 
having to find the software and then install it by hand).

The other method would use a (manually created) packaging file that 
contains the location of the archive and a mapping between the 
locations of the contents and where they would be on a proper package.

The mapping file would be in the riscpkg folder of the package, and 
the archive would either also be in it, or at another location.

The main advantage would be to allow proper (from the user 
pesrpective) packaging when dependencies don't have the correct 
licence to be packaged normally.

There should also be a way of taking possesion of non managed items 
once a managed version becomes available. There shouldn't be any 
problems with modules, because they merge manually happily enough.

Applications should be treated as version zero and backed up, if it 
exists in the install location.

I do feel the front end should be presented as an App store and there 
should be no fork (or duplication) of the underlying packaging 
mechanism. (Other than as above for fetching completely non packaged 
item).

I would also like the front end to be a filesystem i.e. folders in 
Resources:$ representing:

the configured repositories, (help would get the information, and 
opening would download apps that aren't installed, dragging would 
install to the chosen location, refresh would update from that 
repository)

installed apps (as stubs like in Apps, but in folders matching the 
category)

actual files (the apps could be copied to create a non managed copy, 
or moved so that they are located elsewhere).

There would need to be a configure entry (and a stub to open it) for 
updating.

-- 
Jess Hampshire

Plain text emails with interleaved, trimmed replies please. (RFC 1855)