Yup, I agree, and the progress bar when gathering package info is very nice, as there is no longer this impression that something is "stuck in a loop" there previously was after the "Downloading needed headers" message ;-) From some quick tests on a P2 400MHz, no major speed improvement for me, though.

Hmm, That doesn't entirely shock me. a p2-400 will take longer on the xml import. There may be some ways to cache that but, it's unfortunately the nature of the beast. However, once the metadata is loaded the depresolution should be much faster and it's memory footprint considerably smaller.

run in debug mode 4 and you'll see two numbers print out right before and after the dep resolution.

Those will be start and end times on the dep resolution functions.

Seth: Attached is a quick patch to make --help's output more consistent and 80 columns friendly. I've only tried updating, asking for a non-existing package and creating an rss file... all worked fine.

Thanks matthias.

-sv

On Tue, 2004-08-31 at 10:53, Gilles FABIO wrote:

Hi !

Good work Seth !

Personally, I prefer YUM to APT... But APT has a friendly graphic frontend with Synaptic. Does somebody know a similar project for YUM? I intended to speak about GYUM (http://cobind.com/yumgui.html). Is it really performant? Does someone use it? I'll be interested to translate it into french langage if it's a better alternative to APT-Synaptic.

I think the yum 2.1.X code will make writing a gui considerably easier.

-sv

GYUM is a UI abomination, but otherwise, it works. I sent in a big list of UI suggestions and reasoning to the GYUM devs and never got a response - no idea if they plan on fixing the UI to be sane or leaving it the ugly, unusable mess that it is.

It'd probably be easier to just write a fresh GUI from scratch using the proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is indicating.

Here's a wacky idea, What about using system-config-packages as the front end?

That might be a useful project, hooking s-c-p and yum up together.

-sv

seth vidal wrote:

...

GYUM is a UI abomination, but otherwise, it works. I sent in a big list of UI suggestions and reasoning to the GYUM devs and never got a response - no idea if they plan on fixing the UI to be sane or leaving it the ugly, unusable mess that it is.

It'd probably be easier to just write a fresh GUI from scratch using the proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is indicating.

Here's a wacky idea, What about using system-config-packages as the front end?

You are definately thinking way outside of the box there my friend.

The standard operating method for any OpenSource project is to.. look at existing products, think their code is crap and only a rewrite will fix it, start a new project on SourceForge/Freshmeat with your complete rewrite of code, start an IRC channel, and wait for developers to send you patches.

After 6 months, either send out a flaming email about how the OpenSource community was too jealous of your code to help you out OR have a little community of users that worship your code and they will send out regular emails to any other project that they should tow the line and join your project or fear the Jihad.

Trying to work with existing code is almost revolutionary in concept.

That might be a useful project, hooking s-c-p and yum up together.

-sv

seth vidal wrote:

On Tue, 2004-08-31 at 10:55 -0600, Stephen J Smoogen wrote:

...

Trying to work with existing code is almost revolutionary in concept.

You forgot to close your sarcasm tag.

here. I'll do it for you.

</sarcasm>

you know. re-reading - it might be a </cynical> tag.

Sorry

</sarcasm></cynical></tired>

:)

-sv

Where is yum-arch ?

Regards, Tomo

Barry K. Nathan wrote:

On Thu, Sep 02, 2004 at 08:31:49AM +0200, Tomo Vuckovic wrote:

...

Where is yum-arch ?

I guess this isn't a direct answer to your question, but it may be better than nothing... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131415

-Barry K. Nathan barryn@pobox.com

Thanks.

Regards, Tomo

seth vidal (skvidal@phy.duke.edu) said:

yum-arch will be returning to yum for people who want to use the new yum but have to maintain old repos.

it's in the works now.

I could have sworn Paul was just going to patch it into createrepo.

Bill

The createrepo command works only on Fedora Core 2?

I tried it on Fedora Core 1 and Red Hat 9 but I got an error like this one:

7/105 - mozilla-js-debugger-1.7.2-0.2.0.i386.rpmTraceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 488, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 423, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 286, in doPkgMetadata node = dumpMetadata.generateXML(basedoc, baseroot, formatns, mdobj, cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 507, in generateXML value = utf8String(value) File "/usr/share/createrepo/dumpMetadata.py", line 92, in utf8String x = unicode(string, 'ascii') TypeError: coercing to Unicode: need string or buffer, NoneType found

Can I do something to fix this problem?

Unfortunately my repository are on Fedora Core 1 or RH9 machines! :-(

Lorenzo

On Thu, 2004-09-02 at 15:04 -0400, Bill Nottingham wrote:

...

seth vidal (skvidal@phy.duke.edu) said:

...

yum-arch will be returning to yum for people who want to use the new yum but have to maintain old repos.

it's in the works now.

I could have sworn Paul was just going to patch it into createrepo.

no, not into createrepo. That would be bad. putting into yum would be better.

-sv

On Fri, 2004-09-03 at 21:06, seth vidal wrote:

On Fri, 2004-09-03 at 14:00, Lorenzo Luconi Trombacchi wrote:

...

The createrepo command works only on Fedora Core 2?

I tried it on Fedora Core 1 and Red Hat 9 but I got an error like this one:

...

Can I do something to fix this problem?

Unfortunately my repository are on Fedora Core 1 or RH9 machines! :-(

install createrepo 0.3.6 from here: http://linux.duke.edu/metadata/generate/

0.3.6 works fine on fc1 and rhl9 machines. 0.3.7 had a patch added that requires a newer libxml2, iirc. I'll get it fixed up.

I don't think this particular traceback has anything to do with libxml2, but tagByName() behaving differently on FC2 and < FC2 (seemingly a rpm, rpm-python or python difference). The attached patch should fix this particular case.

On Tue, 2004-08-31 at 12:41 -0400, seth vidal wrote:

...

GYUM is a UI abomination, but otherwise, it works. I sent in a big list of UI suggestions and reasoning to the GYUM devs and never got a response - no idea if they plan on fixing the UI to be sane or leaving it the ugly, unusable mess that it is.

It'd probably be easier to just write a fresh GUI from scratch using the proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is indicating.

Here's a wacky idea, What about using system-config-packages as the front end?

Ya, that would work, too. ;-)

Better also if you can get system-install-packages hooked up with those two tools, so that when I grab a package from somewhere other than a registered yum repository, dependencies can still be resolved and installed.

It'd also be nice if yum supported 'temporary' repositories that were passed to it on the command line or through library calls, so, for example, an application RPM could include some meta-data pointing toa repository containing dependencies, so users don't have to a) manually add the repository to their yum.conf or b) manually download all the dependencies.

That might be a useful project, hooking s-c-p and yum up together.

-sv

On Tue, 2004-08-31 at 14:36 -0400, Jeremy Katz wrote:

On Tue, 2004-08-31 at 14:05 -0400, Sean Middleditch wrote:

...

Better also if you can get system-install-packages hooked up with those two tools, so that when I grab a package from somewhere other than a registered yum repository, dependencies can still be resolved and installed.

Funny, system-install-packages will resolve with the system packages (using the same stuff as system-config-packages; realistically, they're the same code with slightly different code paths for UI and one or two other things). The hope with hooking yum into things would be for this to be possible :)

Ah, yes, right. I tried installing a package with a dependency on the base CDs and it asked for it. Without YUM integration it just can't handle most of the packages found online, though.

...

It'd also be nice if yum supported 'temporary' repositories that were passed to it on the command line or through library calls, so, for example, an application RPM could include some meta-data pointing toa repository containing dependencies, so users don't have to a) manually add the repository to their yum.conf or b) manually download all the dependencies.

Hrmmm, that's an interesting thought. Although with yum 2.1, you can just grab a snippet and drop it in /etc/yum.repos.d (instead of having to modify /etc/yum.conf) which makes it a little bit easier to begin with.

That's not bad. That would also then allow the repository to be checked for updated as well.

The integration could be through RPM meta-data, or one could make a new XML format for describing a single package and any related repositories. With a browser/bonobo plugin, one could go a good step towards Mike Hearn's dream of package installation. Have an icon on a web site where clicking it would install an app and any dependencies, and the icon (by being a plugin) would be able to change its appearance/state during and after installation.

Simply having a tool that can grep a simple XML file with a list of packages and possibly some additional repositories would be a simpler first step. Something like:

<?xml version="1.0"> <install> <package>myapp</package> <repository id="myrepo">http://mysite.com/yum/</repository> </install>

The app would install all the package entries listed, and use the listed repo(s) to find the package and any dependencies. An application web site would just have a link to that file and the app would be installed. Take it to the next level with the browser plugin, and we'd have hella- easy software installation.

Also, imagine a CD with some software. The autorun script might open an HTML page on the CD with a big "Install" button linking to an install info file on the CD, which specifies the main package to install and points a YUM repository also on the CD. Again, hella-easy software installation. The entire fact that a packaging system is even being used becomes something the user doesn't need to know (assuming the installer UI is made nice and clean; then system-install-packages UI right now is fairly clearly a geek tool).

Alternatively, another possibility would be to simply reuse the comps database file format. The install tool would open up a GUI showing only the packages listed in the opened comps.xml file, which would then give us the ability to have "components" (i.e. multiple packages with some being optional) similar to what other systems have.

Imagine Mozilla including such a file on their web site. User clicks, the GUI opens up showing the Mozilla components (Browser, Mail, Chat, etc.). User selects the ones they want and then the RPMs are downloaded and installed.

Obviously won't be a panacea until packages and developers start making their software easily installable (i.e., library authors need to learn about proper versioning, and package authors need to learn about making packages that take advantage of libraries that are properly versioned), but it would be a good ways better than what we have now.

Jeremy

On Wed, 2004-09-01 at 10:25 -0400, seth vidal wrote:

...

It'd also be nice if yum supported 'temporary' repositories that were passed to it on the command line or through library calls, so, for example, an application RPM could include some meta-data pointing toa repository containing dependencies, so users don't have to a) manually add the repository to their yum.conf or b) manually download all the dependencies.

It seems to me that a 'temporary' repository is a root kit waiting to happen.

It's no worse than users installing any other RPM. If you don't trust the source, don't use it. Certainly with signed RPMs and a little bit of clue on the part of the user unintentional installation of untrusted packages can be avoided. So long as you have someone who doesn't know or doesn't care about good security, you're not going to stop them from installing something malicious.

The temporary repository in this example would only be ever referenced during the initial installation of the application RPM - if the vendor of the RPM wanted to install malicious code, there is no reason for them to put it in a separate package instead of just putting the code directly in the app RPM.

-sv

On Tue, 2004-08-31 at 15:13 -0400, Nathan Fredrickson wrote:

On Tue, 2004-08-31 at 11:05, Sean Middleditch wrote:

...

Synaptic is anything but friendly. It is a direct, raw wrapping of the apt command-line. You still have to actually understand how apt works, what the different between update, upgrade, and dist-upgrade are, have to deal with the lack of categorization in RPM packages, etc.

Have you tried a recent version of synaptic? It has received a large amount of UI polish in the past couple of months. In particular, update/upgrade/dist-upgrade have been replaced by refresh/apply. Searching, progress indicators, and context menu are greatly improved too. I'd love to see a comparable tool for YUM.

Nice. Guess they're finally getting around to handling all the UI suggestion bugs I filed. Sorry for bad mouthing them based on an old version. ^^;

Nathan

On Fri, 2004-09-03 at 12:01 +0200, Axel Thimm wrote:

On Tue, Aug 31, 2004 at 03:16:31AM -0400, seth vidal wrote:

...

I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- based repository metadata (http://linux.duke.edu/metadata).

NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH REPOSITORIES.

will a future yum support both legacy yum repos and new-metadata repos (I hope it will)? If not could new-yum and old-yum be rearranged in such a way as to allow concurrent installs?

On Fri, 2004-09-03 at 22:18, seth vidal wrote:

On Fri, 2004-09-03 at 16:17, Iago Rubio wrote:

...

On Tue, 2004-08-31 at 09:16, seth vidal wrote:

...

What needs to be done:

• translations

Attached the spanish one.

Hope this helps.

Thank you, but the strings in the program are changing quite a bit right now as there are some explanations that are unfortunately unclear.

I should ask you before to start the translation, my fault.

I'll be begging for translations before long though.

Ok, please post it here when ready - or feel free to mail me privately - if you need help with the spanish translation.

Regards.