Re: ITP: namazu2
At Fri, 18 Feb 2000 18:34:08 +0900 (JST),
Miles Bader <miles@ccs.mt.nec.co.jp> wrote:
> Because it's ugly to have lots of packages with random numbers
> appended to their names.
>
> In some cases, perhaps it's unavoidable, but it should be a last resort.
I simulated this situation.
Currently, we have namazu version 1, which is a single package,
and now namazu version 2 is about to be installed.
Fortunately, namazu version 1 has no shared library, so it seems
to be no problem to upload namazu version 2 as package 'namazu'
except for "Upgrading index file".
namazu_1.x -(method to upgrade index file in script?)- namazu_2.x -->
At the future point, say namazu version 3 will be released.
If we have packages that depends on libnmz2, then we must
need to have libnmz2.
namazu_1.x -- namazu_2.x -->
(libnmz2)
|
hoge depends on +
If namazu version 3 will be uploaded as namazu_3.x, then
there is a libnmz2 that has no source package in Debian.
namazu_1.x -- namazu_2.x --> namazu_3.x -->
(libnmz2) (libnmz3)
| |
hoge depends on + |
|
arege depends on +
On the other hand, if we split namazu into separate packages:
namazu_1.x ---->
namazu2 ----------------->
(libnmz2) namazu3 ------|---------->
| (libnmz3) |
hoge depends on + | |
| (time when hoge ported to use libnmz3)
arege depends on +
In the former, advantages are:
1. package name is always 'namazu'.
2. debian package system knows that namzu is upgraded clearly.
i.e. any process something to upgrade the incompatibility in
maintainer script (such as postgresql?)
but disadvantage is:
1. there is no source archive of libnmz2.
i.e. I wonder whether this is legal for debian policy.
at least 'no source' is GPL violation.
^^^^^^^^^^^^^^
So in the former case, the only following structure can be available.
namazu2 (source) -------------------->
+ namazu (remove namazu)
+ libnmz2 +libnmz2
namazu3 (source) ------------------>
+ namazu
+ libnmz3
This shows that a lastest namazu source includes a latest namazu program
and old namazu sources include only libraries.
There are some packages that adopt this way in Debian, such as ncurses.
Next, in the latter case:
This is similar to improvment of the former (i.e. separate source
package with each version), but it has multiple namazu programs
with each version appended to their names.
namazu2 (source) -------------------->
+ namazu2
+ libnmz2 namazu3 (source) ------------------>
+ namazu3
+ libnmz3
(each namazu has an alternative name to namazu?)
There are some packages that adopt this way in Debian, such as TCL/TK.
And now let us think two ways for namazu.
One of the problem about namazu is a difference of index file between
two versions.
In the former case, the namazu program must have a backward compatibility.
i.e. new namazu can recognize old index files, backward mode, or translation
of these index files.
I don't know that the new namazu can do it (wara
If namazu can't do it easily, most of users would be confused.
In the latter case, there are many namazu folks in Debian at the same time.
This way would be needed if someone makes many scripts using old namazu
interface. This situation is similar to TCL/TK's scripts.
I have no idea which way does namazu has to adopt because of my ignorance
about it. However, to split packages may be better in the
cases such as incompatibility, specifically evil interface of the past
version.
* whether multiple namazu programs are needed.
i.e. namazu execution interface, stability, memory, speed etc.
* whether time is needed to move the system to a new namazu.
i.e. needs to coexistence between multiple versions.
* whether the new namazu can handle this old index file easily.
Whether or not, we need multiple source archives.
Maybe Mr. Kitame announced to make a package 'namazu2' after thinking twice
about that :)
--
Masato Taruishi (taru@debian.org)
Reply to: