Hi Jason,
This is already quite old but I had the same problem...
> > Apt should check dependencies of installed packages against their
> > respective dependencies and not against what is in the packages
> > file.
>
> Unfortunately this is not really reasonable. Adding the complexity
> of having the same version of a package be possibly different is
> just too much to deal with.
Great! So what should I do if I want to install packages from unstable
into a stable system? I do not want to upgrade a production machine to
unstable but there is a package in unstable that compiles cleanly
against the versions from slink.
With apt I can not use it because it refuses to install anything else
afterwards because the packages are broken!?
> All packages with the same version number must be identically
> equivilant, end of story.
This is more simple to handle for apt but I think it is a big problem.
Not every user wants to edit the control file to get a newer version.
BTW apt-get source supports compiling source automagically. But I
can't use it because the generated debs conflict with the ones from
packages.gz...
> > For now, I bypass this problem by building a "myapt" package (I
> > only had to change one line in debian/rules for this) and
> > installing this instead of "apt".
>
> All you need to do is bump the version number to an NMU. [...] I
> really don't think this is something that can be considered an APT
> bug, there is no acceptable alternative.
Hmm, what happens if I bump the version number and try to upgrade
sometime in the future? If there is no newer package then - will apt
downgrade the package to make it compatible with the new ones? I did
not read the dependency code but I think it would think I have a newer
version while it is actually incompatible with the new libc, gtk,
whatever.
This is a workaround, but I still think this should be changed. If you
believe this is a no-bug, why didn't you close the bugreport btw?
Thanks
Torsten
Attachment:
pgpahXyZaId2x.pgp
Description: PGP signature