On Tue, 2003-10-14 at 10:25, Grigory Bakunov wrote: > seth vidal wrote: > > >Suggestion: > > If you're going to send patches with new features - make the patches > >for HEAD, not for 2.0.X - this feature, if it were to get in this form > >AT ALL would not get in to 2.0.X. > > > > > Sorry, i'll do it cause in HEAD i don't see 'po/' folder for example and > some files > disapear to. > try to do 'cvs update -dPA -r HEAD' in your yum cvs directory - you'll > see it too :) > I'll fix it this evening. I didn't know that part was broken - my local tree is fine - hence the problem. > Heh, i make two variables ([u]mountcommand in yum.conf)- if you dislike > current model > just set it to empty line or /bin/false - and then yum just ask for new > disk and don't > try to eject/mount. Do you think what this behaviour must be default? I think automatically ejecting/umounting filesystems is NOT something that I ever want yum to do. it's too error prone and doesn't belong internally. if a user is changing disks, they can probably handle umounting a drive. > little blackmail: > Can i expect what this idea (removable support) appear in yum CVS ? :) possibly > > Also I have lots of patches to yum (and this bored i18n patch too!) :) some of your patches I don't agree with how they are implemented and in some cases _what_ is implemented. I'd also like it if patches were queued in via bugzilla - and referenced on the mailing list. wrt the i18n patch - I applied part of that the other night but I've not done a check in yet. > Yes, i like this idea but how can i get DISKLABEL from cd? :) its on the disk. look in the disk information iirc. > How about this idea: > yum -Rredhat9(3) /mnt/cdrom > Then grab 3 cd and write to header.info something like this: > > 0:name-1.1-1.i386=NUMBER/path/to/name-1.1-1.i386.rpm that's really really yuck-o syntax. I'm focusing on making yum cleaner syntax and simpler to use. Think gnome config dialogs since gnome 2.0. -sv