Re: Packages should not Conflict on the basis of duplicate functionality
> 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.
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,
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, 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. Either you do it the
Debian way and package up sillycommercialpop with a Provides
pop3-server and maybe a Conflicts pop3-server if you're feeling
vindictive, and then you install the deb, or you never rely
on Debian's automation again.
When I recommend to people that they use kernel-package
instead of DIY, they are usually a bit shocked.
Reply to: