seth vidal wrote:
Some other brainstorms as I've been sitting around and talking to folks
on jabber and irc. Some of these are things to add into yum, others are
just things to implement as yum-utils - but feedback on the stupidity of
some of these items is welcome, in no particular order:
1. supporting gpg/x509 signatures detached from repomd.xml on each repo
- so we can check the content for validity
Sounds like a good thing.
2. yum-util system-sync - to make two systems more or less identical
pkg-wise to each other (maybe also spit out a %packages section to a
ks.cfg, too)
Sound good too.
3. taking the 'tolerant' config option in yum and using it to implement
what the --skip-broken plugin does (more or less) but internal to yum
+1, It is implemented as a class, so i could be move into yum, then it
could be called by the yum-cli and the gui's.
A more advanced approach is to build it into the depsolver, so it
contruct a list packages with problems, there can be skipped
if the option is set. It could be made default like in apt-get,
reporting that the following packages could not be updated because for
dep errors.
4. in general look at the plugins and utils and see what features would
be better off in the base code or vice-versa. Is there core code that
should really go live in a plugin
Sound good to me, maybe some priorities or protectbase stuff, to make it
easier to protect base packages from being overwritten
på other repos.
5. yum-gate - take the code that rnorwood posted and maybe work on
making it more releasable for folks to use as an authenticated yum repo.
Alternatively, look at one of the other system-config-mgmt tools to work
for that.
I have just got some patches from another IBM'er, that make changes to
UG and yum to support a client side SSL cert. I will post it on the list.
6. YumBase.install() has a pattern=pkgglob kwarg it takes, remove() and
update() don't. I want to fix that. If for no other reason than to make
the yum cli code simpler.
Any of those things seem cool or silly?
-sv
* Switch from CVS to a distributed SCM like mercurial.
* yum list vendors
List install packages and the rpm vendors, there have been a lot of
discussions on the EPEL list, about repotag as a way to locate the
source of the packages, because the basic packages tools like yum
don't show it in a simple way.
* make some generic callback handler in yumbase there can be subcased by
applications using yum API.
Example:
http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/yumex/src/yumgui/callbacks.py?view=markup.
* yumlets :-)
A sort of metapackage that contains a collection of packages and yum
metadat, a sort of mini repo compressed into a single file.
It could be very useful in there part of world where the broadband
connection is very expensive.
It could work like this.
yum install /path/or/url/to/yumlet.
Then yum would extract the packages and metadata in at special local
yumlets repo cache and install the packages from there.
Tim
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
