Subject: Local packages - how to handle them ?

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 00:44 BST

People often want to install local versions of things, and it is good
to allow them to use our tools to do this.

One of the ways I do this is to have a `local' area supported in
dselect.

Another thing that people have asked for is a way to get dselect to
automatically use a local copy of some things, or to stop it from
`upgrading' to the distribution's version.

Some people have done this by creating differently-named local
versions of the packages in question; this is perhaps a good solution
to the problem as currently exists, but doesn't strike me as generally
optimal - we ought to be able to support this better.

I can see at least two things I could do that would make life easier
for these people, which I'll describe below.  It would be good if
people could have a discussion about their needs and how they are or
aren't met by these or other schemes, so I can decide where to put my
effort.

1st additional feature:

Extend the version number syntax in a way that means that certain
version numbers are (a) reserved for locally-generated packages and
(b) always considered `more recent' than all other numbers.  Perhaps a
range of `locality' would be useful here.

This would mean that you could `dpkg -i' the local package, and
dselect wouldn't ever upgrade it from the distribution, because the
distribution's version would be older.

I might combine this by giving dpkg better handling of archives with
two versions of something: for example, it could skip a package that
was less recent than the one it thinks is `available' - but of course,
this would break when the Packages file is newer than the rest of a
mirror.  Alternatively, I could introduce special-case code so that if
it thought that a `local' version was thought to be available and
selected it would not install an un-local one.  These kinds of special
handling would make it possible to put the local packages in the local
subtree and have dselect install them automatically.  Without any
changes to dpkg in this area you could do this, but the first dselect
`install' run would probably unpack first the standard version and
then the local one.  In any case dselect wouldn't ever replace a local
package with a non-local one.

2nd additional feature:

One or two new `want' flags in dselect, a bit like `hold', but meaning
`local-only'.  The first one (`permanent hold', perhaps) would be just
like `hold' but wouldn't be unset by using `dpkg' on the package
directly (perhaps I should just make hold like this anyway?).

The second (`local only' perhaps) would have an effect on dselect's
access methods.  The default would be for dpkg not to process such
packages (treat them as if they were on hold), but the access methods
would pass a flag to dpkg to allow them to be processed only when they
were running dpkg on the `local' area (as defined by the access
method).

Ian.

---

From: Jon Rabone <[email-masked]>
Date: Tue, 16 Jul 1996 09:45:18 +0100 (BST)

> aren't met by these or other schemes, so I can decide where to put my

<snip>

First off, this is a very good idea - I've needed to  make local versions 
of things, and the hold feature of dselect was the only way I could find 
of stopping things being clobbered. I would suggest support for a 'local' 
packages hierarchy, with its own access method. Dselect would 
automatically treat packages from this tree as latest-version. I can 
forsee a problem with packages that have dependecies on a particular 
version number - perhaps an Overrides: field in the control file is 
needed to resolve this? OTOH, perhaps the Depends: field checking in dpkg 
can be made aware of the 'local' feature, and make this transparent.

It would be nice to have an indication of 'locality' in the filename of 
the package, as Ian suggests. How about prefixing the version number with 
the letter L ? 

FWIW I think 'hold' should not be cleared by installing a package manually
using dpkg -i. Addding more hold flags to dselect could make it cumbersome
to use. You could just add an L flag (for local) in dselect, meaning
'Don't get this one from the primary access method, wait for the secondary
access method' This, in combination with the different filenames and
enhanced Depends: handling would provide the required functionality,
wouldn't it? 

Just my thoughts.

Jon. 

/-----------J. K. Rabone-----------\ "There's a picture, I like to look at
| http://club.eng.cam.ac.uk/~93jkr |  A picture of a beautiful face.
|    Email: [email-masked]    |  And I see something, in her eyes
\--------Phone 01223 331547--------/  Sends me to a better place..."

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 15:23 BST

Jon Rabone writes ("Re: Local packages - how to handle them ?"):
...
> can be made aware of the 'local' feature, and make this transparent.

If we're not using the version number then you can just make sure that
your local version of the package has the right version.

> the package, as Ian suggests. How about prefixing the version number with 

If we're doing it via dselect using a different access method and a
different tree there's no need for this.

> enhanced Depends: handling would provide the required functionality,

Mmm.

Ian.

---

From: [email-masked] (Heiko Schlittermann)
Date: Wed, 17 Jul 1996 08:19:05 +0200 (MET DST)

Jon Rabone wrote:
: 
: It would be nice to have an indication of 'locality' in the filename of 
: the package, as Ian suggests. How about prefixing the version number with 
: the letter L ? 

For packages I don't want to get updated automagically from dselect
I choose (as supposed in the kernel-source package) a name like
name-1.0-local7.deb.  However, a new mainstream version updates.

For packages I want to get updated I choose name-1.0-7local.deb.

It's the way _I_ understood the deb naming and versioning scheme.  (But
this nice (?) approach breakes in several debian.rules when the debian
version is in- or decremented.

    Heiko
--
email : [email-masked] [email-masked] [email-masked]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [email-masked]         [email-masked]

---

From: Juergen Menden <[email-masked]>
Date: Tue, 16 Jul 1996 14:32:21 +0200 (MET DST)

> range of `locality' would be useful here.

   hello_l-1.2.3-4.deb: local overrides even newer distribution
   hello_1.2.3-4-l.deb: new distributed overrides local one

i think there are no version strings starting or ending with l-
resp -l.

version ordering rule (#1, #2 are nowadays version numbers): 
  l-#1 >= l-#2  iff  #1 >= #2
  l-#1 >  #2
  
  #1-l >= #2-l  iff  #1 >= #2
  #1-l >  #2    iff  #1 >= #2
  #1   >  #2-l  iff  #1 >  #2

my $0.02

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: Michael Shields <[email-masked]>
Date: Tue, 23 Jul 1996 22:01:57 +0000

>optimal - we ought to be able to support this better.

I've been thinking about doing this with "realms".

A package could be provided independently from seperate realms.   Version
numbers from different realms are incomparable; it would be up to the user
to decide which realm they wanted to install a package from.  I could run
dselect and see two versions of a package presented -- one from the
debian.org realm and another from the crosslink.net realm.

This would make dependencies more complicated.  If package foo from the
stock Debian tree wants to have bar >2.0-5, and I've installed bar
[email-masked], should foo be installed?  Since versions are not
comparable between realms, dpkg would have to ask the user whether
[email-masked] was more current than [email-masked], and maybe save
that information for future use.  This isn't perfect, but there's no way to
have perfection without having an actual release that's produced under
central control (as the Debian releases are).

dselect would inform you when a new version appeared regardless of realm,
but would only upgrade by default when a new version appeared within the
same realm as the version already installed.

--
Shields, CrossLink.