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