Re: A real package manager in action

I demand that Colin Granville may or may not have written...

In message <XAE*Gimbr@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Theo Markettos <theom+news@xxxxxxxxxxxxxxxxxxxxxx> wrote:
[snip]
I think the main difference between the Debian model and the one we're
discussing here is that Debian has separate concepts of 'upstream' and
'maintainer'. The maintainer is the person who does the packaging, and is
not necessarily the original author who is upstream. The maintainer may
change (people don't need to maintain a package for life) so Debian holds
things centrally so that a change of maintainer doesn't affect the
distribution system.

I don't know about any linux system nor am I fluent in linux speak so
you'll forgive me if I misunderstand something.

Splitting the responsibility for managing the package from the author is
instantly doubling the things that can go wrong.

But it means that the author ("upstream maintainer", if you like) doesn't
need to know about the details of N different distributions and doesn't have
to worry about packaging. It also spreads the support load: package
maintainers (should) act as filters for bug reports, feature requests and
patches, sending some of it on upstream.

For exmaple, in the VNC Server case I discussed earlier in this thread we
have an original author (HBP) who has 'abadoned' his software (no offence
to HBP, just I mean there have been no updates for 4 years). However the
original author hasn't handed the baton on to someone else, he's just put
the source on his website. His website doesn't 404, it's still there,
it's still claiming to be the latest version. But it isn't, because
someone else has taken on development (well, actually two someones who
probably don't know the other exists).

Yes but the new version is effectively a new program. There could be 17
versions spawned from the original after all the original source is free
which one is best?

Whichever has the features which you need and fewest bugs.

It's not something a package manager can decide.

True...

If the program you have isn't being updated any more or the link breaks and
you want a better program then you have to find a program that is better
not update your version to another program.

Sometimes that update is exactly what's needed - the home site may have been
moved.

That someone can't access HBP's website, because it's his personal site.
So any links in HBP's version of the software will refer to an old website
that still exists and still claims to be up to date. By indirecting
somewhere that's independent from the authors involved the package
management system can be sure that it can trust it has the latest package
out there.

see above - redirection not necessarily good. In an open source system the
author may continue to update but someone else may use the source for a
competing version. Everyone acclaims the new version as far better should
the maintainer redirect the link?

That's entirely up to him.

This has political issues because (for example in the Castle/ROL SCL
scenario) someone needs to decide which stream they want to follow.
That's why it can be helpful to have a maintainer who isn't in charge of
upstream. Of course RISC OS currently doesn't have the manpower for all of
this so it might be moot.

I'm afraid to me it's never better to relinquish control to a maintainer -
may be a necessary evil but not better

Relinquish? Pull the other one. You can grab stuff from the maintainer's site
and integrate it into your (upstream) package if it's useful.

Maintainers (packagers) don't have to send patches etc. upstream, but it's
good practice to do so. I've raided package sites for patches on occasion...
:-)

[snip]
1) Atomicity. You can know that the package state transits from one
consistent state to another. You can't know this if the packages are
changing underneath you. In Debian you get a list of the available
packages (a snapshot) and then use that to work out dependencies. If you
were crawling many sites for the package information that could be
changing as you download it, resulting in inconsistency.

It also means that you can't use the system on a user basis on your own web
site and if one of your resources isn't controlled by the package manager
it's useless.

Sort of. It depends what the resource is, and the worst that can happen is
that the package manager thinks that the resource is unavailable and either
won't install the dependent package or will fetch the resource, potentially
overwriting what you have locally.

2) All-or-nothing. What happens if you try to download some packages but
one package's website is down?

then the author gets to know and puts it right as opposed to the package
manager getting to know and putting it right.

You want one point of failure rather than two?

If you're downloading 1000 packages from 1000 sites which depend on each
other in complicated ways there's quite good chances one or other of those
sites will be down. If it's a vital package missing then you can't
install many of the others without it. If it's a vital package that
disappears permanently then everyone is stuck until all the authors change
their description files to point to a new location. If you have all
packages on a set of mirrors and one is down you just switch to a mirror
that's up.

If a resource is removed by an author the same thing would happen.The
author needs to know if a resource disappears

True. Sometimes this is communicated by package maintainers, and not
necessarily those of your program; e.g. <URL:http://bugs.debian.org/353892>.

it is not up to a package manager maintainer to decide that a different
resource will do.

Yes it is, if that resource also provides the needed functionality in a
compatible way. Again, the maintainer may inform upstream and, if needed,
also provide a patch.

So as the author has to find and check a replacement [it's] easy enough at
that stage to update a link.

Perhaps. But using official repositories is better :-)

All you are doing is the equivalent of giving everyone a website on the
same server except at least if you did that you'd have the option not to
have your package maintained by the maintainer and locate your resource
elsewhere.

Just be careful about that - while you may make a better job of producing the
program, the maintainer may make a better job of producing the package.

3) CDs. You can dump the entire package state on a CD and give it to
someone to install on a networkless machine. In a distributed system
you'd have to get a list of packages and crawl them to download everything
(see 1 and 2)

That's easily done on a distributed system after all the internet works
just like 1 big hard disc.

Oh good. So what happens if I run mke2fs or similar on it? ;-)

4) Abstraction from upstream/ability to takeover package maintenance (see
above)

taking over packages is not as obvious as it sounds. I may have a program,
stop developing it, someone else develops it on another site. I decide to
continue developement some time later. which program is the development of
the original program?

Both.

[snip]
I'm not suggesting everything on one website (use mirrors if you like) but
one central package list. If you really want to have the packages
themselves on distributed servers then do that, but it doesn't gain very
much.

If you distribute the packages then a central package list is also
unnecessary

It's still very useful, though. Without it, you may as well have lots of
package lists and more potential for conflict than with the central list.

as it restricts you to using programs in the package list.

How so?

Anyway just think of the problems people have keeping link lists up to date
why should a package list be any different.

It'd be automatically generated from the packages available in that archive.
Where's the problem?

[snip]
--
| Darren Salt | d @ youmustbejoking,demon,co,uk | nr. Ashington, | Toon
| RISC OS, Linux | s zap,tartarus,org | Northumberland | Army
| Kill all extremists!

Expect a letter from a friend who will ask a favour of you.
.

Relevant Pages

  • Regarding unresponsive Debian maintainers (was: Re: Open-Source environments for Java)
    ... package anymore and won't be stalling the project (or, at least, the users ... > without any indication of an intent to fix them. ... any response from the maintainer. ... I merged some bugs there. ...
    (Debian-User)
  • Re: Back Again
    ... The whole reason for the epoch is the automatic assumption regarding version and release numbers. ... If just replace the built-in version-release succession assumption with a resource definition. ... This becomes just another type of a package resource -- the updated resource. ... And if the original upstream versions are what's retarded, you just version the packages properly, and don't worry about it. ...
    (Fedora)
  • Re: sylpheed updates on Fedora
    ... There seems to be only one maintainer to whom BZ requests are ... Co-maintainers can choose not to be added to ... Some package owners don't like to have co-maintainers. ...
    (Fedora)
  • Re: Linux and viruses, worms, etc (newbie)
    ... sorts of mistakes to watch out for. ... So, having one package maintainer ... maintainer then becomes something of a single point of failure. ...
    (alt.os.linux.suse)
  • Re: Want to give away new app free for Linux
    ... from other developers in porting it to the various distro package formats ... maintainers, for example, tend to view upstream inclusion of debian ... a package maintainer is likely to know how to package software ... for his chosen distribution better than its "jack of all distributions" ...
    (comp.os.linux.misc)