Re: A real package manager in action

In message <a8c49c064e.colin@colin/granville.gmx.co.uk>
Colin Granville <colin.granville@xxxxxxxxx> wrote:

In message <0ab5fd054e.tigger@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Nick Roberts <tigger@xxxxxxxxxxxxxxxxxxxxx> wrote:

In message <92d3ec054e.colin@colin/granville.gmx.co.uk>
Colin Granville <colin.granville@xxxxxxxxx> wrote:


If you avoid the issue how to install at 3 at the moment, this
can be achieved now with RO programs as follows.

1) use google or a links site like Paul Vigays to find the
program.

It's already more hard work for the user than a package manager
would be, but we'll let that ride.

Should we also let ride that sites like PV's are always out of
date?

and a package manager is never out of date?

PV's site is always out of date because it relies on one person to
maintain links to all the products. A package manager (or rather, the
central repository) is maintained by everyone who has a package on it.
It's thus much more likely to be up to date. If BookMaker is packaged,
all I have to do is update the package description.

I update a program to an alternative branch but don't inform the
package manager cos I can't be bothered - easier to just stick it on
a web site.

Having experimented with a BookMaker package, it really is a trivial
extra task once the (fairly minor) effort to understand the format of
the package description and the package control file. For example, the
BookMaker one for RiscPkg is:

-------------------------------------
Package: BookMaker
Priority: Optional
Section: Misc
Version: 2.12
License: Non-free
Maintainer: Nick Roberts, tigger@xxxxxxxxxxxxxxxxxxxxx
Standards-Version: 0.0.0.0
URL: http://tigger.orpheusweb.co.uk/bookmaker/BkMkrPkg.zip
Description: A hotlist/address book manager supporting most major
RiscOS browsers, email, FTP and Telnet clients.
-------------------------------------

How much extra effort is it to update that compared to "just sticking
it on a web site"?

In fact, arguably it's less effort - if package management becomes the
de facto standard way of distributing software, I don't have to update
the HTML that points to the distribution.

2) just fetch the program with a browser. The programs website
doesn't have tell you or carry links to resources.

3) put the program where you want it and run it. Now the
programs run file instead of causing an error when a
resource is missing it sets a flag in a system variable. If
no resources are missing it runs the program. However if the
flag is not 0 instead of running the program it runs a html
file which says 'You do not have the resources to run this
program fetch resources?' and the file has a link to a
website or possibly a disk.

Here is where it can go wrong. I put a command file inside
BookMaker to say look at site <x> for module <y>, and people
download that version of BookMaker. The problem is, since I put
that version of BookMaker up, the producer of the module has moved
it. You have thus moved the onus of tracking the location of all
the dependent modules onto the programmer. I have enough demands on
my time without having to spend a chunk of time every day making
sure that none of the programs on my web site are now referring to
out-of-date web pages.

Yes the onus has to be the programmer because only he knows that the
resource on the moved site is the one he wants to use.

That's silly. If the resource is package-managed, I can rely on the
provider of the resource to do it for me.


With a package manager, I just have to state in the package file
that BookMaker depends on version <v> of module <y>. I don't have
to tell it where to find module <y> - that's the responsibility of
the person maintaining the module.

It can never be the responsibility of the person maintaining the
module as it is not up to that person to say that the redirected
resource does the same as the old

If you take this to its logical conclusion, then no program can depend
on a resource written by anyone else - which means that it will be
impossible to develop anything sizable.

Tell me, do you rely on the toolbox? How do you know that a new release
of them will not do something different?

I don't want anyone other than me
deciding which resources to use for my programs

It is no different to a site - like paul vigays - being used as a
lookup table. You pass the address where you expect to find a
resource as a parameter to PV's site. His site then looks up that
address in a database and redirects you to the the current page.
That requires either PV to maintain the links or the programs owner
to maintain his own link. You are saying that PV (sorry Paul it's
only an example) can't keep his links database up to date so why
should he be able to keep a lookup table up to date and by analogy
why should a Program manager maintainer be any different.

Because there is a huge difference in scale! Paul is trying to provide
a links site to every piece of RISC OS software, and doing it all
himself.

This is hugely different to me contributing a dozen programs to a
package resource center, and agreeing to maintain the links to those
dozen programs. As the contributor, I know when I move my web site; as
does every other contributor. As a maintainer of a links page, Paul has
no idea when a resource is moved.

4) the link to the website has a version number and the missing
resource flags attached to it.


5) The fetched html file tells you if there is a newer version
available - if there is one - otherwise it doesn't mention
it, links to similar products which are available and a list
of links to fetch resources that you don't have (which are
listed depends on the flags passed in the url).

6) you fetch all the resources listed and install them.

You are now adding in a whle load extra manual installation work
for the user. But that's fair - you've aleady put a large burden on
the programmer, so I guess it's only far to spread the grief
around.

Why the emotive language we are discussing this rationally aren't we?

I wasn't trying to get violently emotional, just add a touch of humour.
Perhaps I should have added a smiley - sorry.


Why not let the maintainer write the dependency file after all you
have already written it in your !run file and he can work it out from
that.

I've put no exta burden on the programmer. It is always the
responsibility of the programmer to ensure that a program uses the
correct resources otherwise the program wouldn't work - in the present
manual system that the correct resources are recommended.

It has, however, always been the case that any links to resources used
may lag behind the movement of those resources. A package manager
completely avoids these issues.

Extra programming by the programmer is negligible.

Minimal extra programming, yes. But compared to what a PM offers, a
potentially huge amount of programmer time. If the package
contributors follow the rules, when a new version is released or a
resource moves, the maintainer of that package updates the package
central resource, and everything falls into place. When an end user
installs the dependent program, the correct resource is fetched
automatically. Under your mandraulic system, the program will not run,
and will provide an outdated link. This will lead to an email to the
developer of the dependent package, who will either have to search for
resource himself, or will have to tell the end user how to find it. I
just don't see how it can be argued that this is better.


I was illustrating what can be done now with minimum effort. You want
to go on step further and introduce installers but as I have shown
this isn't necessary for package management. The issue of installers
and package management is a separate issue, I gather linux has package
management with installers - the installer may be integrated into the
package management system but they are installers all the same. Any
system just fetches files and installs them

7) you run the program again and it works.

The only extra work for the programmer is a script on their website
to tailor the file fetched to the users requirements.

You've missed the fact that the programmer has to continually monitor
the web sites of the dependent utilities to make sure they haven't
moved. This is _not_ a trivial amount of time.

It is a lot easier for a programmer to maintain his resource links
than to maintain the resource links for every program ever made -
something only achieved at the moment by google.

The whole is that the programmer doesn't _have_ to maintain resource
links for every program ever made. He has to maintain the links for
_his_ programs. So long as the other contributors to the central
resource maintain the links for their programs, the system will work.

Obviously not from your own experience of keeping link sites up to
date

Eh?

I've never tried to keep a link site up to date, as my experience of
such is that they can't be. For example, Paul's site is still
referencing all my programs as being on the argonet web site, despite
the fact that he knows there has been no such web site for about 9
months.

All this can be done now and if you opt for manual installation
doesn't require anyone else to do anything or comply with some
rules or for that matter involve anyone else.

Now if you want automatic installation someone can write a
generic installer and you can drop the fetched resource file into
an installation program and that can take care of it. If you want
manual installation just do what you do now and manage your own
computer.

The only problem with the above is broken links. If one of your
resources changes you can change your script to point to a new
resource or update your program not to use the resource

This touches on my point above. But how do I know that a resource
has moved? I either have to invest a lot of time in continually
monitoring the locations of dependencies, or wait until I get an
email from a not-so-satisfied user that the links refered to in the
program dependency script dont work.

yes the same way as a PM maintainer finds out that the address is
changed - but do you really want someone who knows nothing of your
program effectively telling people to use different resources?

If a program of mine demands a particular extant resource I have a
choice of trusting the provider of that resource, or implementing it
myself. As I have no intention of reimplementing the toolbox, I trust
ROL and Castle not to release a new version that does something
significantly different from the published API.

Why should I assume that the developer of (say) tinct is suddenly going
to have a brainstorm and change the API in a non-backwards-compatible
way?

If the programs link is lost you have to refind it if you want an
update - if there is one. Updating is just matter of sending a
url with a version number and a 0 resource flags. This will tell
you if there are newer versions.

Sorry, you've lost me here. Sending a URL?

I was just illustrating how you would find out about updates. You
have obviously used PM's on linux. From what I gather there are a
number of these - none of them perfect. I have not seen them in
action I am discussing this from first principles.

PMs work the other way round - the user _asks_ for an updated list of
packages, and then asks for new versions of programs that he wants. The
user isn't sent anything.

So why not do it the RISCOS way and provide a separate
application (let's call it a package manager for the moment) to
do that, and let each application get on with doing what it is
good at - word processing, graphics, or whatever.

The program still has to identify its dependencies so the
programmer has to maintain a 'dependancy identifier file' the
location of which is irrelevant to the amount of work necessary.

Yes, but its a one-off. The programmer doesn't have to keep chasing
round all the sites providing these dependencies on the off-chance that
one of them has moved.

But the point is, this dependency file simply states "This program
requires version <v> or module <y>". It definitely does _not_ state
where it is found. It's up to the package manager and mirrored
package repository to provide hat information, so the task of
updating the information whenthe location of a package changes sits
where it should: with the developer of the package.

It does state where to find it.

Sorry, it doesn't. If I'm using a package that is available from the
package manager, it is the responsibility of the provider of the
package to state where it is downloaded from, not the responsibility of
the programmer of the client application.

You are telling the PM to use a certain resource that was available
at the time you created the dependency file for the the package
manager. If the link is changed by the maintainer he is effectively
changing your program without your knowledge.

But the revised resource should be backwards compatible with earlier
releases. If it isn't then it is useless as a general resource, and
won't get used.

It should be up to the programmer to decide if a resource change is
acceptible or whether a program change is necessary.



I can't see anything that your system would do in a half-baked sort
of way that a package manager wouldn't do better and in a more
consistent

It isn't half baked, a package manager as you describe it
requires your program and all its dependencies to be controlled
by the package manager which isn't going to happen.

I'm sorry, it is half-baked. It relies on me, as the developer of a
program, to continually monitor the locations of all the modules
that my program depends on. I don't have enough time to do all the
deveopment I want anyway, and your scheme is to bite deep into what
little time I do have. OTOH, to support a package manager takes
about a few minutes of my time per program to set up the package in
the first place, and a couple of minutes to write the package
description file.

A prototype package manager (albeit one with which I have a lot of
issues) exists. If there was some kind of commitment from ROL (for
eg toolbox modules) and Castle (for eg bit-neutral C99 SharedCLib),
a lot of the rough edges of RiscPkg could be ironed out in a short
time.

I'm afraid I don't agree. The lack of programmer control/flexibility
is not for me and after all it is my program - unlike linux where the
program would be free to everyone and no-one could withdraw.

You want to hand over control of programs for someone else to
administer telling programmers that they have to conform and telling
users that they have to conform to the PM's way of handling apps. I
don't think that is for me. I may as well use linux if it was as it
throws out what I like about RO and just reduces the reasons to use
RO for me.

I've just realised where you are coming from, and I think you are
conflating two quite distinct issues:

(1) Whether the developer of a program should also be the program
distributer and maintainer;

(2) The use of a package manager.

As far as I can see, most of your complaints are against issue (1),
which is completely orthogonal to whether or not one distributes
software via a package manager. I haven't been arguing for (1), but
solely for (2).

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.
.

Relevant Pages

  • Re: A real package manager in action
    ... It's already more hard work for the user than a package manager ... I presume you need to tell it dependencies otherwise there is no ... resource is missing it sets a flag in a system variable. ...
    (comp.sys.acorn.apps)
  • Re: etch help
    ... could not mark all for installation or update ... make sure all required repositories are added and enabled in the preferences ... that means the package manager appears to be functioning ...
    (Debian-User)
  • Re: A real package manager in action
    ... A package manager (or rather, ... The only dependencies that BookMaker has is on minimum version of the ... the resource on the moved site is the one he wants to use. ...
    (comp.sys.acorn.apps)
  • Re: New kernel update hangs the machine at boot
    ... RPM is a great package manager. ... the system installation directories, ...
    (alt.os.linux.suse)
  • Re: problem with load D5 package in D6
    ... have package 'Dolphin Legacy Resource Framework' installed? ... Resource Framework is required to load in old packages and convert view ... !Resource categoriesFor: #accessor!accessing!private! ...
    (comp.lang.smalltalk.dolphin)