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

How to bring life into a (Tk) package?

Dear list,

I want to adopt the package "tktable2.9" but I found me confronted with
some problems:

1. The package name contains the version, and since the upstream version
is now 2.10, I would need to give a new name. 

2. The package was orphaned since 2008 and is removed from unstable (and
testing) now, see but #465957. However, it is still available in stable.

Is this then a new package (so that I need to write an ITP), or is it
still an adoption (and I need to write an ITA)?

3. The Debian Tcl/Tk policy states that the modules should be named
"tk-table". My package, however is called "tktable2.10" (src) and
"libtktable2.10" (binary). Is this a good moment for a name change, so
that both (src and binary) are called "tk-table" (without version
number)? If yes, how should I state the dependencies? In the moment,
they are:

Replaces: tktable, tktable-dev, libtktable, libtktable-dev
Conflicts: tktable, tktable-dev, libtktable, libtktable-dev

since some time ago (~7 years from now) the versioned package was
introduced. What is the best way to fix this?

On the build side, I find the policy quite confusing: It says "Build
dependencies for Tcl/Tk dependent packages must be declared for every
Tcl/Tk version, that the package is built for. In order to build for a
specific version, add the versioned Tcl/Tk packages dependencies; it is
generally better and recommended depending on the appropriate default
packages with an eventual strict or relaxed versioning."

Since the package can be build for 8.4 as well as for 8.5, what should I
put into the Build-Depends and Depends? The old package used 

Build-Depends: [...] tcl8.4-dev, tk8.4-dev

Depends: [...] tcl|tcl8.5|tcl8.4|tcl8.3, tk|tk8.5|tk8.4|tk8.3

Is it OK to just replace that with the unversioned relationships?

Best regards


Reply to: