[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP: namazu2

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

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: