Smart package manager (Was: Same named packages, different dependencies)

[Axel Thimm]

On Thu, Dec 09, 2004 at 12:50:03PM +0100, Dag Wieers wrote:
> With smart you can decide what repositories you trust to be
> upgrading your system by default, which ones cannot override core
> packages and even which repositories are prefered on a per package
> basis.

In theory you could do that with apt, too, but there were bugs or at
least the documenation was not in sync with the code (meaning the code
did behave differently than the docs specified).

In general having such a system is not a bad idea. Of course long term
the reasons for prioritizing repos should be examined and fixed. OTOH
we know that some issues with repos not being compatible to users by
definition have been attacked quite often in the last 1 1/2 year and
still were not resolved. So there is definitely a need for such a
system.

There will be bugs in using prioritized repo structure, such as A
requiring a fixed package B, which is forbidden to be upgraded by
smart/apt due to priority rules. In order to overcome such a situation
B would have to provide B-feature-X-is-fixed and A depend on this.

Currently the assumption is that since A and B are maintained in the
same repo, such implicit dependencies/properties are seldomly cast
into the specfile. Creating dependencies on specific releases also
makes the package less generic and portable.

An example would be transcode, which can have a lot of different
support in its baggage. smart itself would be another example, which
requires a patched up rpm, which ATrpms provides, but from a package
POV is indistinguishable from a non-patched rpm (there are no extra
Provides). Using smart from ATrpms for say Red Hat 7.3 w/o using the
patched up rpm will do no good.

The bottom line seems to be, if there will be support from repos for
prioritizing schemes, each package need to be considered outside of it
own repo context, which is quite hard to do. OTOH it rises the
packaging quality of that package, and it will make it cross-repo
friendlier will even make it more cross-distro friendly.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20041209/a6b3ca29/attachment-0002.bin 
-------------- next part --------------
-- 
fedora-list mailing list
fedora-list at redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list