gnewsense-dev
[Top][All Lists]
Advanced

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

[Gnewsense-dev] Re: No xv?


From: Yavor Doganov
Subject: [Gnewsense-dev] Re: No xv?
Date: Mon, 08 Mar 2010 20:01:24 +0200
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

> I hope not -- it would be confusing to call a package by that name
> if it weren't the xv program.

There might be another `xv' program that is a free replacement of `xv'
(just like the GNU implementation of `m4', `awk', etc.) or something
entirely different; renames happen all the time.  There is a reason
why dpkg/apt/etc never had any restriction wrt package names.

> This problem is easily solved.  If a name exists as a package,
> cancel the name from the delete list.

Exists as a package where?  APT has no knowledge where the package
comes from (at this stage, at least).  It is perfectly legitimate
practice to upload a package to a personal repository (or a an APT
repository that is internal/private for a particular network).

> I have nothing against solving the problem that way, as long as it is
> solved somehow.

Well, if Karl and/or the other gNS maintainers do not object, I can
provide a patch for deltah (I don't have a metad installation so I
can't test).  I agree with you that this is a problem that has to be
fixed, and it doesn't involve only `xv'.  But it's up to the gNS
developers to be addressed.

> But we must not be intimidated by changing programs from Debian.

If the change is unavoidable and is the right thing to do, sure.  In
this case, it doesn't even fall in the category "shooting sparrows
with a cannon".

IMHO it is really the wrong thing to hardcode package names in APT.
This doesn't solve the problems for other backends (aptitude, (x)ara,
synaptic, adept, software-center, etc.) and is something that would be
percieved as a perverse thing to do considering that the Debian
package system was designed to solve these kind of issues on a
per-package basis via the control fields instead of hardcoding
relationships in package managers.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]