|
Home > Archive > Debian Developers > May 2005 > Proper use of Replaces
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Proper use of Replaces
|
|
| Roberto C. Sanchez 2005-05-27, 8:48 pm |
| I am working on taking over toshutils. One of the things I would like
to do is incorporate a patch that updates it from GTK+ to GTK2. The
patch came from ALT Linux.
Up to now I have been considering keeping the toshutils package as it is
and then adding a second binary package from the same source, called
toshutils-gtk2. However, in reading the Policy Manual about the use of
Replaces, I am not sure how to proceed. The Policy Manual states that
it is a violation of policy for a pacakge to contain files in the same
location as another package without replacing it. Specifically:
"It is an error for a package to contain files which are on the system in
another package, unless Replaces is used"
This leaves me in the akward position of having toshutils and
toshutils-gtk2 both Conflict and Replace each other. That doesn't really
make sense.
I have a few options:
1) Setup toshutils-gtk2 to compile binaries to have different names and
maybe not have them Conflict.
2) Have both packages use the same binary names, remove the Conflict and
set them up to use alternatives.
3) Forget about a GTK+ version and press ahead with a GTK2 only package.
4) Forget about a GTK2 version and press ahead with a GTK+ only package.
I would like to know what everyone thinks.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
| |
| Steve Langasek 2005-05-27, 8:48 pm |
| On Fri, May 27, 2005 at 09:43:26PM -0400, Roberto C. Sanchez wrote:
> I am working on taking over toshutils. One of the things I would like
> to do is incorporate a patch that updates it from GTK+ to GTK2. The
> patch came from ALT Linux.
> Up to now I have been considering keeping the toshutils package as it is
> and then adding a second binary package from the same source, called
> toshutils-gtk2. However, in reading the Policy Manual about the use of
> Replaces, I am not sure how to proceed. The Policy Manual states that
> it is a violation of policy for a pacakge to contain files in the same
> location as another package without replacing it. Specifically:
> "It is an error for a package to contain files which are on the system in
> another package, unless Replaces is used"
> This leaves me in the akward position of having toshutils and
> toshutils-gtk2 both Conflict and Replace each other. That doesn't really
> make sense.
> I have a few options:
> 1) Setup toshutils-gtk2 to compile binaries to have different names and
> maybe not have them Conflict.
> 2) Have both packages use the same binary names, remove the Conflict and
> set them up to use alternatives.
> 3) Forget about a GTK+ version and press ahead with a GTK2 only package.
> 4) Forget about a GTK2 version and press ahead with a GTK+ only package.
> I would like to know what everyone thinks.
Forget about the GTK+ 1.2 version, so we can let that library die?
--
Steve Langasek
postmodern programmer
| |
| Roberto C. Sanchez 2005-05-28, 7:48 am |
| On Fri, May 27, 2005 at 06:59:10PM -0700, Steve Langasek wrote:
> On Fri, May 27, 2005 at 09:43:26PM -0400, Roberto C. Sanchez wrote:
>
>
>
>
>
>
>
> Forget about the GTK+ 1.2 version, so we can let that library die?
>
Good. That is what I wanted to do, but I wasn't sure how it would go
over. Second question, how do handle the version numbering? Increment
only the Debian part of the version and include the GTK2 patch as a
Debian patch? Patch the original source and sort of make my own "new
upstream release" and increment that main version number?
Also, should I plan this bing uploaded to unstable or experimental?
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
| |
| Raphael Hertzog 2005-05-28, 5:49 pm |
| Le samedi 28 mai 2005 à 08:35 -0400, Roberto C. Sanchez a écrit :
> Good. That is what I wanted to do, but I wasn't sure how it would go
> over. Second question, how do handle the version numbering? Increment
> only the Debian part of the version and include the GTK2 patch as a
> Debian patch? Patch the original source and sort of make my own "new
> upstream release" and increment that main version number?
I wouldn't touch the upstream version unless you're really taking over
upstream maintenance... is your upstream dead ?
Including the patch in the debian diff is quite common nowadays. You can
always use a build system that applies patches at build time rather than
patching by hand before generating the .deb ... those system let you
quickly add/remove patches.
You can check for example how I did it in libdbdpg-perl (I borrowed it
from someone else).
> Also, should I plan this bing uploaded to unstable or experimental?
It depends... I'd wait a few fays until sarge is released and then
upload it to unstable. (Uploading right now probably wouldn't hurt since
it's not a library but ... if you discover a RC bug for sarge, then
you're forced to use t-p-u)
Regards,
--
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kevin Mark 2005-05-28, 8:47 pm |
| On Sat, May 28, 2005 at 08:35:22AM -0400, Roberto C. Sanchez wrote:
> On Fri, May 27, 2005 at 06:59:10PM -0700, Steve Langasek wrote:
<toshutils new version plan>[vbcol=seagreen]
>
> Good. That is what I wanted to do, but I wasn't sure how it would go
> over. Second question, how do handle the version numbering? Increment
> only the Debian part of the version and include the GTK2 patch as a
> Debian patch? Patch the original source and sort of make my own "new
> upstream release" and increment that main version number?
>
> Also, should I plan this bing uploaded to unstable or experimental?
>
> -Roberto
Hi Steve and Roberto,
I noticed that Roberto as a new contributer was unsure as to wheather to
keep using gtk 1.x or to move his app to 2.x. Is there any refernce for
say RELEASES as to what libraries are to be transitioned to a certain
version? I recall seeing RC issues about libmysql being mentioned. Was
there somewhere someone could have gone to read about what version was
expected to be used in SARGE and thus would have been able to better
plan a tranistion for his/her app? Is this just 'general knowledge' in
Debian, to any app developer or would this be good to have listsed as a
design goal for a release (on the website)?
Just curious.
Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
`$' $'
$ $ _
,d$$$g$ ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b
,$P' `$ ,$P' `Y$ $$' `$ $ "' `$ $$' `$
$$ $ $$ggggg$ $ $ $ ,$P"" $ $ $
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $
`Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
| |
| Steve Langasek 2005-05-28, 8:47 pm |
| On Sat, May 28, 2005 at 07:17:38PM -0400, Kevin Mark wrote:
> On Sat, May 28, 2005 at 08:35:22AM -0400, Roberto C. Sanchez wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> Hi Steve and Roberto,
> I noticed that Roberto as a new contributer was unsure as to wheather to
> keep using gtk 1.x or to move his app to 2.x. Is there any refernce for
> say RELEASES as to what libraries are to be transitioned to a certain
> version? I recall seeing RC issues about libmysql being mentioned. Was
> there somewhere someone could have gone to read about what version was
> expected to be used in SARGE and thus would have been able to better
> plan a tranistion for his/her app? Is this just 'general knowledge' in
> Debian, to any app developer or would this be good to have listsed as a
> design goal for a release (on the website)?
> Just curious.
It's usually a pretty safe bet that the newest version of the library
present in both testing and unstable is the one to use. Other than that, if
you have questions about which to use you probably want to talk to the
library maintainers about their plans.
--
Steve Langasek
postmodern programmer
|
|
|
|
|