Re: A real package manager in action

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:

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

In message <3902fa044e.colin@colin/granville.gmx.co.uk>
Colin Granville <colin.granville@xxxxxxxxx> wrote:
[SNIP]

I may have missed something obvious, designed what already exists
or repeated what everyone has said - just my thoughts anyway.

As far as I can see, what you've missed is that every application
that supports this sysem would have to have about 80% of the
functionality of a package manager.

Package management can be broken down into the following phases

1) finding a program

2) fetching the program

3) installing the program

4) identifying any resources you don't already have

5) repeating from 1 for any resourse you don't already have.

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

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.

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

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?

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. Extra
programming by the programmer is negligible.

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.

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


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


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.

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

An interesting discussion - at least I've cleared things up in my own
mind.


--
Colin
.

Relevant Pages

  • Re: A real package manager in action
    ... if a resource was missing (equivalent of the ... listed depends on the flags passed in the url). ... Now if you want automatic installation someone can write a generic ... (let's call it a package manager for the moment) ...
    (comp.sys.acorn.apps)
  • 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: A real package manager in action
    ... It's already more hard work for the user than a package manager ... resource is missing it sets a flag in a system variable. ... You are now adding in a whle load extra manual installation work ...
    (comp.sys.acorn.apps)
  • Re: A real package manager in action
    ... persuade for a package manager to achieve the same thing so you get more ... author to keep the dependancy file up to date - as it would have to be ... Then the author has to find another source of the resource which will ... What advantages are there in having a centralised site as opposed ...
    (comp.sys.acorn.apps)
  • Re: A real package manager in action
    ... that program from whereever and just dropping it where I want to use ... info dbox saying 'update me'. ... if a resource was missing (equivalent of the ... (let's call it a package manager for the moment) ...
    (comp.sys.acorn.apps)