Re: New package containing binaries with same name as some from the packages cons, pscan and hsffig.
On Mon, May 28, 2007 at 11:15:31PM +0900, Charles Plessy wrote: > Dear Hwei, Uwe and John, > > I did not manage to contact you in private (see below), therefore by > policy 10.1 I have to move the discussion on debian-devel (copy sent > to debian-med). We (the members of the pkg-emboss project on Alioth) > have uploaded a new package in the experimental section of Debian, > emboss, which provides binary program with similar names as your > packages. Actually, there were two replies to your original email, which raises some concerns over the possible approaches you raised. I did receive those emails, but did not reply because I didn't have anything further to add at the time. > I would like to discuss what is the best solution to this problem for > our users. We have already explored a few possible directions on the > debian-med mailing list: > > http://lists.debian.org/debian-med/2007/04/msg00075.html > http://lists.debian.org/debian-med/2007/05/msg0.html > (The thread is split on two months) > > Basically, the plan would be to provide the binaries under their > original names in /usr/lib, and symlinks in /usr/bin. With such a > setup, a user can set his PATH in order to have access to the original > names of the binary programs. This sounds like the best solution, since these conflicting binaries *are* a part of the EMBOSS suite. I don't think it's a good idea to remove other, standalone packages just because one suite happens to have a conflicting name. The programs in a suite should be used together, and if users don't use the suite, they should be able to use the conflicting names for something else. Perhaps you can use debconf to prompt the user whether to setup the symlinks to the EMBOSS binaries? (Hopefully this is not a wrong use of debconf.) That way, regular users of EMBOSS get the appropriate warning that some binaries may not be available in the default path, and get a chance to change that if they so choose, and users who may want to use the conflicting names for other packages can continue to do so without undue interference. > However, if I do not get answers, I will suppose that nobody cares > about the packages cons, pscan and/or hsffig anymore, and will request > their removal rather than complicating the things for the users of > EMBOSS. [...] One of the larger issues this particular case brings up is what to do with packages that contain binaries with overly-generic names. For example, 'convert' in ImageMagick: it is only an image converter, but the name can easily be used for other kinds of conversion. It seems almost inevitable that one day somebody else will create another program named 'convert'. We should have some kind of mechanism to deal with that. --T signature.asc Description: Digital signature
Re: New package containing binaries with same name as some from the packages cons, pscan and hsffig.
Le Mon, May 28, 2007 at 08:36:05AM -0700, H. S. Teoh a écrit : > On Mon, May 28, 2007 at 11:15:31PM +0900, Charles Plessy wrote: > > Dear Hwei, Uwe and John, > > > > I did not manage to contact you in private (see below), therefore by > > policy 10.1 I have to move the discussion on debian-devel (copy sent > > to debian-med). We (the members of the pkg-emboss project on Alioth) > > have uploaded a new package in the experimental section of Debian, > > emboss, which provides binary program with similar names as your > > packages. > > Actually, there were two replies to your original email, which raises > some concerns over the possible approaches you raised. I did receive > those emails, but did not reply because I didn't have anything further > to add at the time. Dear Hwei, thank you for your answer. I am sorry that I was unclear in my emails: I was actually waiting a bit more than one month for answers ... Also, I am not saying that packages having conflicting binaries should be removed, just that packages having serious bugs and no answer from the maintainer for a dozen of weeks should be orphaned and either adopted or removed. The way to deal with trivial binary names is indeed challenging and we did not find a good solution for the problem, especially if we want to provide an abstraction layer to the user. For instance, with Debconf, I do not think that we can manipulate the PATH of users which are not yet created, and in the case of EMBOSS, a command line suite of programs, it is likely to be a limitation. I proposed two ideas in the past discussion, mostly for the sake of it, but I admit they are not very convincing: - having the two packages which contain conflicting binaries shipping the same wrapper. - detecting some strong cues for the interest for one package, such as the use of a particular CDD, and try to change the binary names accordingly. In our particular case, in which we have not many users, and apparently non-overlapping userbases, another problem is that any solution is likely to annoy 99.9 % of the users and help 0.1 %... which is not interesting now that we have less than 100 users ! Anyway, for the moment my plan is to implement the /usr/lib workaround, and submit serious bugs next week to pscan and hsffig if I do not get answer... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]