Re: Possible solution to Local dependency satisfaction
On Fri, 24 Jan 1997, Jean Pierre LeJacq wrote:
> On Fri, 24 Jan 1997, Dale Scheetz wrote:
>
> > One of the biggest problems with the current packaging system (ignoring
> > issues of dselect interfaces) is that there is no mechanism for satisfying
> > dependencies with programs that are located in /usr/local.
> > If the sys admin builds a sendmail package of their own and installs it in
> > /usr/local, dpkg and dselect have no current mechanism for recognizing
> > that fact and trys to force the installation of sendmail anyway.
> > If dpkg/dselect were able to check a file in /usr/local and obtain
> > dependency information from that file then the sys admin could declare
> > dependencies there for packages existing in /usr/local.
> > If dpkg looks for a file called .depends in /usr/local and considers all
> > dependencies listed there as fulfilled, this would greatly aid the local
> > sys admin in maintaining the system as desired.
> > The file need only contain lines like:
> >
> > sendmail 8.8.4
> >
> > to give dpkg the necessary information to decide about dependency
> > satisfaction.
>
> Why is this a problem? Isn't the correct approach to build
> a local version of the debian package that installs into
> /usr/local? The version number who have to indicate that its
> ahead of the standard debian package. I've been doing this
> for a while now but installing into /opt.
Well, this is the first I have heard of this kind of solution. Asside from
the fact that it violates one of the Debian package rules (don't touch
/usr/local) which is only a philosophical problem under these
circumstances, it doesn't resolve the target problem. Many system
administrators want to use a particular version of a piece of software. In
a debian system the proper way to keep your program from being interfered
with is to install it in /usr/local, since most upstream source defaults
to installing in /usr/local this isn't hard to do. You just download the
upstream source and build the package as the upstream maintainer intended.
However, when you do this, dpkg has no knowledge of your actions. My
intention was to provide an "easy" way for the system administrator to
notify dpkg that the dependency has been satisfied.
>
> What I do find problematic is the inability of keeping
> several versions of a package. This is necessary for us
> since we need to evaluate our products against all the
> possible versions of a product our customer base may have.
> The current approach seems to be to rename the package and
> all the files within the package.
>
This is another problem all together. Without much thought my response
should be taken with a grain of salt, but, what we do for libraries could
work in this case. What you would have to do is rebuild the package with
the version included in the package name. Then dpkg will install each on
the same system. Of course it is more complex than that, for instance, you
will need to rename the binaries as well, or you will only end up with the
latest install being the functional one. Depending on the individual
package there may be other issues that require renaming or moving things
to alternate locations. Like I said, I haven't really thought about this
much...
Luck,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
------------ If you don't see what you want, just ask --------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: