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

Re: Packages should not Conflict on the basis of duplicate functionality



On Wed, Sep 29, 1999 at 10:38:34PM -0400, Clint Adams wrote:
> > read the rest of my message. the bit that ranted about unix's that
> > get in the way of DIY.  RH is one. sun's Netra is another...both are
> > examples of how NOT to do configuration management on unix.
> 
> No.  You're talking about doing something your way and then having
> it wrecked by the RH/whatever way.  And if you decide to do something
> your way in conflict with the Debian way, Debian may wreck your work
> too.

debian provides methods of having your cake and eating it too. it
provides tools for integrating your custom changes into the debian
system so that you don't ever have to worry about the system screwing up
your custom stuff.


> If I'm running /usr/local/sbin/sillycommercialpop3d, or
> /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck,
> and I want to install php72-pop3 which Requires pop3-server,

this is what the dummy package (or whatever it is called is for). fake
up as many Provides: lines as you need.

> and I naively apt-get install php72-pop3, not thinking it would
> require a local pop server or thinking that my pop server should
> be sufficient, 

if you suffer from this naivety then you need to cure it. expecting
software to magically perform some miracle is not going to help you do
anything but dig yourself into a much deeper hole.


> I'd probably end up with a nice little tagalog pop server that
> installs itself in inetd and steals the port.  There are two simple
> solutions to this.

this would be a problem caused by insufficient knowledge/experience on
the part of the operator. don't fix the symptom, it'll just come back
again...fix the cause instead.


> Either you do it the Debian way and package up sillycommercialpop with
> a Provides pop3-server

yep, this is another good way of doing it. like the dummy package you
get to DIY and still retain the benefits of the packaging system.

if you don't like that, then there distributions which don't provide
such useful system administration tools. try slackware, for example.



> When I recommend to people that they use kernel-package instead of
> DIY, they are usually a bit shocked.

kernel-package is a useful tool which helps to DIY. it doesn't conflict
with the notion of DIY at all, it makes it easier...especially if you
like to compile your kernels on your fastest machine and then ship them
out with scp to wherever they are needed.


craig

--
craig sanders


Reply to: