Re: [Cooker] urpmi features
On Tue 2003-03-25 at 10:24:23 -0800, [EMAIL PROTECTED] wrote: [...] > > Of course, doing it all in a nicely scrolling Konsole window works fine for > > me, here, but if we are going to have a GUI, we might as well make it a > > decently functional one, usable by power users as well as newbies, and > > continuing to support new back-end options, even without new versions of the > > GUI every time the back-end changes. > > One request for the gui here... a select all updates button. when doing > a new install 3 months after release it can be real time consuming to > check each and every update one by one by one by one (you get the > idea) I am not sure if you are talking about rpmdrake, but if you do, you can simply click on the checkbox right of the "> Upgradable" headline (well, after selecting "all packages by update availability", of course). HTH, Benjamin. pgp0.pgp Description: PGP signature
Re: [Cooker] urpmi features
On Tue, 2003-03-25 at 04:08, Duncan wrote: > On Tue 25 Mar 2003 03:05, Guillaume Rousse posted as excerpted below: > > Ainsi parlait eddie : > > > > > > > > > > Please use standard text for email. > > No kidding! > > > > Then you should talk to Texstar @ Pclinuxonline. He had a great system > > > with apt-get and Synaptic that worked with a Gui and worked wonderful, > > > although he doesn't have the time to maintain two update mirrors. If > > > one guy can maintain a program like that, why can't Mandrake? > > > > Nobody told this wasn't possible. Just that isn't a priority. Developping > > GUI is heavy and costly, especially compared to adding a switch in CLI. If > > you want advanced options, you're supposed to be an advanced user, meaning > > able to read the doc and a shell prompt... > > What I'd like to see is a solution I've seen elsewhere.. > > 1) After adding any usual GUI-ified options as thought appropriate, have a > text box (or a page of text boxes for a multi-function app that calls > multiple other tools and/or calls a single tool in multiple contexts) where > the user can add additional command line switches and params as so desired. > The only support needed is to provide the text boxes, one per context, and > ensure that their contents gets passed when the specified tool is called > within that specified context. > > One example of the above that I've been working with lately is K3B, the KDE > CD/DVD image burning software front-end to the various ripping/burning/isofs > tools. In it's prefs dialog, it has an entire page/tab listing the various > back end tools, with a text box beside each, in which you can add advanced > switches as appropriate. Those that don't know about the additional switches > and/or don't want/need to bother with them (like me, for the most part) can > just leave them blank, but the several of the back end tools it invokes have > all sorts of corner-case command line options unneeded by most folks, and > having those text boxes, for additional switches to be added at invocation, > means a lot of folks can use the GUI, that would otherwise have to use the > command line, or a different front end that provided such options. > > 2) A (perhaps optional) popup, that lists the progress details and any > errors, as the process progresses. One of the big reasons (besides the lack > of advanced options in the GUI) I use URPMI rather than the various GUI > utils, is that the command line version lists the stuff as it downloads, and > I can see where something stalls, if it does. When I'm updating multiple > source lists, and I see the internet activity stop for to long a time, > without returning a success or failure dialog, on the graphical tools, I have > no way of knowing where the hold-up is. With the command line, I can > immediately see what mirror isn't responding, or whatever other problem may > be occuring. In addition, I like seeing the scrolling status, as the > individual components are d/led. A popup window with the same info scrolled > in its display on the GUI version would be very nice... > > An example of this is what KPackage does, when installing an RPM. It pops up > a status window, with the various commands and results as they would normally > be output on the command line, if one were to invoke rpm from there. Now, in > KPackage, it isn't normally such a big deal, because the process isn't so > long, with so many steps, as a multi-mirror update, and then an urpmi > --auto-select is, but giving GURPMI or Software Installer or whatever the > graphical title of the month is now, the same sort of update progress window, > would be very useful. (The optional part of it could be handled with a > simple checkbox, either as a global option in some settings dialog, or on a > per-task basis, right before clicking the "go" button.) > > Of course, doing it all in a nicely scrolling Konsole window works fine for > me, here, but if we are going to have a GUI, we might as well make it a > decently functional one, usable by power users as well as newbies, and > continuing to support new back-end options, even without new versions of the > GUI every time the back-end changes. One request for the gui here... a select all updates button. when doing a new install 3 months after release it can be real time consuming to check each and every update one by one by one by one (you get the idea) James
Re: [Cooker] urpmi features
On Tue 25 Mar 2003 03:05, Guillaume Rousse posted as excerpted below: > Ainsi parlait eddie : > > > > > > Please use standard text for email. No kidding! > > Then you should talk to Texstar @ Pclinuxonline. He had a great system > > with apt-get and Synaptic that worked with a Gui and worked wonderful, > > although he doesn't have the time to maintain two update mirrors. If > > one guy can maintain a program like that, why can't Mandrake? > > Nobody told this wasn't possible. Just that isn't a priority. Developping > GUI is heavy and costly, especially compared to adding a switch in CLI. If > you want advanced options, you're supposed to be an advanced user, meaning > able to read the doc and a shell prompt... What I'd like to see is a solution I've seen elsewhere.. 1) After adding any usual GUI-ified options as thought appropriate, have a text box (or a page of text boxes for a multi-function app that calls multiple other tools and/or calls a single tool in multiple contexts) where the user can add additional command line switches and params as so desired. The only support needed is to provide the text boxes, one per context, and ensure that their contents gets passed when the specified tool is called within that specified context. One example of the above that I've been working with lately is K3B, the KDE CD/DVD image burning software front-end to the various ripping/burning/isofs tools. In it's prefs dialog, it has an entire page/tab listing the various back end tools, with a text box beside each, in which you can add advanced switches as appropriate. Those that don't know about the additional switches and/or don't want/need to bother with them (like me, for the most part) can just leave them blank, but the several of the back end tools it invokes have all sorts of corner-case command line options unneeded by most folks, and having those text boxes, for additional switches to be added at invocation, means a lot of folks can use the GUI, that would otherwise have to use the command line, or a different front end that provided such options. 2) A (perhaps optional) popup, that lists the progress details and any errors, as the process progresses. One of the big reasons (besides the lack of advanced options in the GUI) I use URPMI rather than the various GUI utils, is that the command line version lists the stuff as it downloads, and I can see where something stalls, if it does. When I'm updating multiple source lists, and I see the internet activity stop for to long a time, without returning a success or failure dialog, on the graphical tools, I have no way of knowing where the hold-up is. With the command line, I can immediately see what mirror isn't responding, or whatever other problem may be occuring. In addition, I like seeing the scrolling status, as the individual components are d/led. A popup window with the same info scrolled in its display on the GUI version would be very nice... An example of this is what KPackage does, when installing an RPM. It pops up a status window, with the various commands and results as they would normally be output on the command line, if one were to invoke rpm from there. Now, in KPackage, it isn't normally such a big deal, because the process isn't so long, with so many steps, as a multi-mirror update, and then an urpmi --auto-select is, but giving GURPMI or Software Installer or whatever the graphical title of the month is now, the same sort of update progress window, would be very useful. (The optional part of it could be handled with a simple checkbox, either as a global option in some settings dialog, or on a per-task basis, right before clicking the "go" button.) Of course, doing it all in a nicely scrolling Konsole window works fine for me, here, but if we are going to have a GUI, we might as well make it a decently functional one, usable by power users as well as newbies, and continuing to support new back-end options, even without new versions of the GUI every time the back-end changes. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
On Mon, Mar 17, 2003 at 06:35:02PM +0100, François Pons wrote: > > Any other idea are wellcome. I'd suggest making it possible to query packages that are not installed. The best thing I could achieve is to dump the raw headers with urpmq which is not easy to read. I used to use rpmdrake to search for stuff in all packages but it is quite hard to do since there is one app that shows installed packages and other that shows only packages not yet installed. urpmq can dump the header so it is almost there.
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 eddie wrote: > Guillaume Cottenceau wrote: > Then you should talk to Texstar @ Pclinuxonline. Tex can speak for himself, though he doesn't seem to like cooker ... > He had a great system > with apt-get and Synaptic that worked with a Gui and worked wonderful, > although he doesn't have the time to maintain two update mirrors. If one > guy can maintain a program like that, why can't Mandrake? You do know that all he did was maintain the sources lists for apt? synaptic is available for any distro that has apt available. And why do we need a duplicate system, when urpmi/rpmdrake work well, and the same lists etc are used by installation? Oh, maybe we should use Debian's installer also ;-). Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+gDj6rJK6UGDSBKcRAvwgAJ9qXiYxungAgLNSVE6ckiyvnulknQCeIEjY nXpGD5ohV0w2WhBd5Ygx/ko= =fIDl -END PGP SIGNATURE-
Re: [Cooker] urpmi features
Ainsi parlait eddie : > > Please use standard text for email. > Then you should talk to Texstar @ Pclinuxonline. He had a great system > with apt-get and Synaptic that worked with a Gui and worked wonderful, > although he doesn't have the time to maintain two update mirrors. If > one guy can maintain a program like that, why can't Mandrake? Nobody told this wasn't possible. Just that isn't a priority. Developping GUI is heavy and costly, especially compared to adding a switch in CLI. If you want advanced options, you're supposed to be an advanced user, meaning able to read the doc and a shell prompt... -- The speed with which components become obsolete is directly proportional to the price of the component. -- Murphy's Computer Laws n°9
Re: [Cooker] urpmi features
Guillaume Cottenceau wrote: Jason Greenwood <[EMAIL PROTECTED]> writes: All my point was, was that there are many functionalities of URPMI (indeed many Mandrake config/admin utils) not available graphically. If these could be made available via a GUI then more newbies would experience their power and advertise it via word of mouth. Not all options are good in the GUI, because maintaining a complicated tool costs time, and maintaining a GUI even more. Some advanced options are not a problem only available in commandline. Then you should talk to Texstar @ Pclinuxonline. He had a great system with apt-get and Synaptic that worked with a Gui and worked wonderful, although he doesn't have the time to maintain two update mirrors. If one guy can maintain a program like that, why can't Mandrake?
Re: [Cooker] urpmi features
Jason Greenwood <[EMAIL PROTECTED]> writes: > All my point was, was that there are many functionalities of > URPMI (indeed many Mandrake config/admin utils) not available > graphically. If these could be made available via a GUI then more > newbies would experience their power and advertise it via word of > mouth. Not all options are good in the GUI, because maintaining a complicated tool costs time, and maintaining a GUI even more. Some advanced options are not a problem only available in commandline. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] urpmi features
[EMAIL PROTECTED] writes: > Quoting Jason Greenwood <[EMAIL PROTECTED]>: > > > ok, where is that option in the gui then?? > > > > I KNOW what it can do from the command line, I mean that these great > > features need to be in the GUI. > > > > Cheers > > > > Jason > > You're right, misread it. But this would be a rpmdrake feature, not urpmi ;) > BTW, yes it would be nice to have an advanced mode in the GUI to have access to > that kind of options. It's already done in grpmi for 9.1: when there has been downloaded files and there was an error, a dialog proposes to remove or not downloaded files (actually there is a bug that makes it show even when errors occur and no file was downloaded). -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] urpmi features
Freenet support? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Greenwood wrote: > My point is that URPMI doesn't resume, precluding the use of it over > dialup (especially with the flakiness of some mirrors). The other thing > is that because it doesn't, I would like to use an ftp client that > supports rsync so I could resume the partial transfer. AFAIK it should resume/continue etc when using an rsync source. > As it is now, I > have to use a regular ftp mirror so I can resume transfers after a > broken connection (which means I become an unwitting bandwidth hog since > even if only 1 byte has changed, I download the whole new cooker package > to test it). cd /var/cache/urpmi/rpms wget -c `urpmq --sources ` Sure, it would be great if urpmi did this, but then it would probably have to check all the RPMS in cache (rpm -K) or attempt to resume them all. Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eErVrJK6UGDSBKcRAmNJAJ9Bq84T4Fc6mbQoRNUlDfSpcbdgtgCgxuU9 b+K4U+C03zRvmhSigvyRiNE= =f9kL -END PGP SIGNATURE-
Re: [Cooker] urpmi features
On Tue 18 Mar 2003 21:40, Steve Fox posted as excerpted below: > On Mon, 2003-03-17 at 17:53, James Sparenberg wrote: > > In a sense doesn't it do this already.. if you open the software sources > > menu the uncheck a source and click save and quit. it will put an > > ignore tag on this item in /etc/urpmi/urpmi.cfg. This source is still > > configured and can be re-activated any time you'd like but for the > > moment urpmi -a and urpmi xx will not access this media. I > > use it all the time for boxes so I don't have to carry disks with me > > everywhere I go. > > Yes, but it's kind of a pain in the butt. A command line switch would be > appreciated. Since I saw the mention above of what the GUI actually does, putting the ignore tag in urpmi.cfg, I've been meaning to give it a try and verify plus check actual formatting, then set up scripts with the appropriate sed commands to insert and remove the ignore tags in the cfg file as needed. That'd do for here, but command line switches to do the same thing properly WOULD be quite useful. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
On Mon, 2003-03-17 at 17:53, James Sparenberg wrote: > In a sense doesn't it do this already.. if you open the software sources > menu the uncheck a source and click save and quit. it will put an > ignore tag on this item in /etc/urpmi/urpmi.cfg. This source is still > configured and can be re-activated any time you'd like but for the > moment urpmi -a and urpmi xx will not access this media. I > use it all the time for boxes so I don't have to carry disks with me > everywhere I go. Yes, but it's kind of a pain in the butt. A command line switch would be appreciated. -- Steve Fox http://k-lug.org
Re: [Cooker] urpmi features
On Tue, 2003-03-18 at 11:29, Duncan wrote: > On Mon 17 Mar 2003 14:50, [EMAIL PROTECTED] posted as excerpted below: > > Quoting Jason Greenwood <[EMAIL PROTECTED]>: > > > It would also be great if dialog box came up before downloading packages > > > > > > that asked if you wanted to keep the rpm's on your system after > > > download. It could also say somehting like, "packages will be held in > > > /var/cache/urpmi/rpms until you delete them" > > > > There is already that option :) > > --noclean > > OK, I already use --noclean in my shortcut scripts. What would be great, > would be if there was an option to ONLY clean if everything installed > properly, but otherwise leave the uninstalled stuff hanging around. I > currently use --noclean, and then go in after the successful installs (if I > remember), and either delete them all manually, or use a null urpmi with the > --clean option, so it cleans everything up. Now, if it fails, I don't have > to re-d/l a bunch of stuff after fixing the problem, which is great, but if I > forget to do the clean, next time there's a problem, and I have to go fix > things up, I have all these stale packages laying around, if I forgot to do > the --clean afterwards, the last time. Duncan, I have had a few ... well more than a few installs via urpmi fail in all this, usually caused when the rpm got upgraded in the list but the new hdlist wasn't yet generated. In each case install failed and all of the downloaded rpms remained on my box. so now I could go in and do rpm -Uvh on what was correct and get it installed. James > > Talking about which... It'd be nice to know WHAT failed, instead of just > getting a "try running urpmi.update" error, without a list of what failed. I > can go installing everything manually, from the d/l dir, until I am left with > the stuff that doesn't install, but that's a pain. It'd be far nicer to have > a list of the problem stuff, so I could go fetch it manually (since the > problem is usually unsynced hdlist.cz's, ez enough to go fetch the new rpms > manually, if I know what they are), and then retry the --autoselect install > again, to do the rest. > > Of course, part of the problem here would be solved with the subgrouping stuff > mentioned, but having a conditional clean, and a list of problem files if > there WAS a problem, would still be quite useful.
Re: [Cooker] urpmi features
On Tue, 2003-03-18 at 11:10, Duncan wrote: > On Mon 17 Mar 2003 10:35, Jean-Michel Dault posted as excerpted below: > > Having multiple servers in a group, and doing a fallback to a random > > server in the list whenever a server is unavailable would make things > > more robust. > > This would be very cool. I could certainly use it. > I like the minimum d/l speed option as well. Interesting thought... client side load balancing. hmmm
Re: [Cooker] urpmi features
My point is that URPMI doesn't resume, precluding the use of it over dialup (especially with the flakiness of some mirrors). The other thing is that because it doesn't, I would like to use an ftp client that supports rsync so I could resume the partial transfer. As it is now, I have to use a regular ftp mirror so I can resume transfers after a broken connection (which means I become an unwitting bandwidth hog since even if only 1 byte has changed, I download the whole new cooker package to test it). Either it needs to be supported in the GUI tools or an ftp client needs to add rsync support. I am just wondering why all ftp servers are not set up to have rsync support? I realise that rsync has to be set up as a different server to the ftp one but really, is this that hard to do?? That way, only partial packages would need to be downloaded. Besides, the no clean option is NOT an option in the GUI, so is not an option for newbies. You missed my point entirely. Cheers Jason Benjamin Pflugmann wrote: On Tue 2003-03-18 at 09:10:38 +1200, [EMAIL PROTECTED] wrote: Urpmi needs to be able to resume if a disconnection occurs and use rsync to get the required differences between packages only IMHO. This would include Cooker packages. Do you mean something different that using an rsync-enabled source and running "urpmi --noclean?". For any rsync solution you need an rsync-enabled mirror anyhow and the second option you already have. I am missing something? Bye, Benjamin.
Re: [Cooker] urpmi features
On Tue 18 Mar 2003 14:38, Todd Lyons posted as excerpted below: > It wasn't too difficult to get working the one time I figured it out. > But your case is complicated by the fact that it doesn't do what you > expected it to. Oh.. (he said, looking disappointed ). Thanks, anyway. At least I know, now. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote on Tue, Mar 18, 2003 at 02:24:15PM -0700 : > > I've been looking for some help with the new parallel options. I'd like to > configure my box such that it could update from several sources at once, or > several items at once, anyway, using the parallel options, as I think should The parallel stuff actually works the other way. It allows you to push out urpm* commands to multiple machines. ie, if you were the sysadmin of 50 machines, you could be on yours and enter urpmi --parallel company packagename and it would connect to the other 49 machines and install the rpm on them. > Definitely, man page documentation on the parallel options would be nice. It wasn't too difficult to get working the one time I figured it out. But your case is complicated by the fact that it doesn't do what you expected it to. Blue skies... Todd - -- | MandrakeSoft USA | Sometimes you get what you want. | | http://www.mandrakesoft.com | Sometimes you get experience.| | http://www.mandrakelinux.com |--unknown origin | Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+d5Hmlp7v05cW2woRAsvxAJ9iPwBbBtpOylZ1Jz70LDpwhi4a2gCfVgU2 ZHjgEPXnB3xw4g3rivhaYLg= =SknY -END PGP SIGNATURE-
Re: [Cooker] urpmi features
On Mon 17 Mar 2003 11:52, Eric Fernandez posted as excerpted below: > Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is > in French, but I have also an english translation. I've been looking for some help with the new parallel options. I'd like to configure my box such that it could update from several sources at once, or several items at once, anyway, using the parallel options, as I think should be possible, but the documentation is a bit sparse to get me going. I've been thinking something along the lines of attempting to set it up with 127.0.0.1, 127.0.0.2, etc, the internal interfaces, hoping the hints that DO exist in the documentation are enough, but haven't tried it yet. Definitely, man page documentation on the parallel options would be nice. Better documentation on the options that can be set up in the config file -- pretty much all there is to go on is the changelog at this point, even worse than the parallel options, would be nice, as well. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [EMAIL PROTECTED] ~]$ urpmf --description kernel-2.4.21 > kernel-2.4.21.0.13mdk:The kernel package contains the Linux kernel > (vmlinuz), the core of your > Mandrake Linux operating system. The kernel handles the basic functions > of the operating system: memory allocation, process allocation, device > input and output, etc. > > What is it exactly that doesn't work for you? I must be missing > something obvious. :-) Right. You used the version number. Well done. So "kernel" is maybe not the best example. But I imagine that you see my point. "urpmf --description kernel" will give you a description of all package which contain files with "kernel" in the pathname (unless I'm mistaken). Which means a lot. It is more obvious with the package "bc", since it doesnt have a version name in its package name. Aurélien - -- http://gauret.free.fr ,--.-'-,--. \ /-~-\ / / )' . . `( \ ( ( ,---. ) ) \ `(_o_o_)' / \ `-' / | |---| | [_] [_] There are only 10 types of people in the world: those who understand binary and those who don't. If you use envelopes, why not encryption ? GPG key available on gauret.free.fr and www.keyserver.net Key ID : 0x1B4259B3 Fingerprint : 4832 1239 8C18 F5F3 C466 AE69 21A6 2396 1B42 59B3 (Note: The last 8 numbers in the fingerprint give the KeyID) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Key ID : 1B4259B3 iD8DBQE+d3eyIaYjlhtCWbMRAoK6AKDuU7ojBZXeOIT/z+5Bu2EDkZ8ANgCfYNEU icKVA23gRXIQhJvLVm7yCEc= =4seD -END PGP SIGNATURE-
Re: [Cooker] urpmi features
On Mon 17 Mar 2003 14:50, [EMAIL PROTECTED] posted as excerpted below: > Quoting Jason Greenwood <[EMAIL PROTECTED]>: > > It would also be great if dialog box came up before downloading packages > > > > that asked if you wanted to keep the rpm's on your system after > > download. It could also say somehting like, "packages will be held in > > /var/cache/urpmi/rpms until you delete them" > > There is already that option :) > --noclean OK, I already use --noclean in my shortcut scripts. What would be great, would be if there was an option to ONLY clean if everything installed properly, but otherwise leave the uninstalled stuff hanging around. I currently use --noclean, and then go in after the successful installs (if I remember), and either delete them all manually, or use a null urpmi with the --clean option, so it cleans everything up. Now, if it fails, I don't have to re-d/l a bunch of stuff after fixing the problem, which is great, but if I forget to do the clean, next time there's a problem, and I have to go fix things up, I have all these stale packages laying around, if I forgot to do the --clean afterwards, the last time. Talking about which... It'd be nice to know WHAT failed, instead of just getting a "try running urpmi.update" error, without a list of what failed. I can go installing everything manually, from the d/l dir, until I am left with the stuff that doesn't install, but that's a pain. It'd be far nicer to have a list of the problem stuff, so I could go fetch it manually (since the problem is usually unsynced hdlist.cz's, ez enough to go fetch the new rpms manually, if I know what they are), and then retry the --autoselect install again, to do the rest. Of course, part of the problem here would be solved with the subgrouping stuff mentioned, but having a conditional clean, and a list of problem files if there WAS a problem, would still be quite useful. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
On Mon 17 Mar 2003 10:35, Jean-Michel Dault posted as excerpted below: > Having multiple servers in a group, and doing a fallback to a random > server in the list whenever a server is unavailable would make things > more robust. This would be very cool. I could certainly use it. I like the minimum d/l speed option as well. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] urpmi features
On Tue, 2003-03-18 at 10:42, Guillaume Rousse wrote: > Le Mardi 18 Mars 2003 19:20, Todd Lyons a écrit : > > Chmouel Boudjnah wrote on Tue, Mar 18, 2003 at 01:53:53PM +0100 : > > > for this stuff you can short it with emacs : > > > > You emacs gurus just amaze me. There is nothing that you cannot do with > > emacs > edit text with only 2 hands and 10 fingers ? ROTFLMAO!!!
Re: [Cooker] urpmi features
Le Mardi 18 Mars 2003 19:20, Todd Lyons a écrit : > Chmouel Boudjnah wrote on Tue, Mar 18, 2003 at 01:53:53PM +0100 : > > for this stuff you can short it with emacs : > > You emacs gurus just amaze me. There is nothing that you cannot do with > emacs edit text with only 2 hands and 10 fingers ? -- If such a program has not crashed yet, it is waiting for a critical moment before it crashes. -- Murphy's Computer Laws n°6
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aurelien Bompard wrote on Tue, Mar 18, 2003 at 11:21:05AM +0100 : > > I totally support that ! Right now only rpmdrake can show you this type of > information. And urpmf --description doesn't count, try to get the > description for the package "bc" or "kernel" to get an idea... :-) [EMAIL PROTECTED] ~]$ urpmf --description kernel-2.4.21 kernel-2.4.21.0.13mdk:The kernel package contains the Linux kernel (vmlinuz), the core of your Mandrake Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. What is it exactly that doesn't work for you? I must be missing something obvious. Blue skies... Todd - -- | MandrakeSoft USA | Sometimes you get what you want. | | http://www.mandrakesoft.com | Sometimes you get experience.| | http://www.mandrakelinux.com |--unknown origin | Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+d2Thlp7v05cW2woRArhmAJ9nysvUOOSTL5JChc8qclV3hb8RpQCfTuUe TcXDxFZ0WbxQ+o3a///75hk= =D/9G -END PGP SIGNATURE-
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chmouel Boudjnah wrote on Tue, Mar 18, 2003 at 01:53:53PM +0100 : > > for this stuff you can short it with emacs : You emacs gurus just amaze me. There is nothing that you cannot do with emacs and I'm constantly amazed at just how powerful it is. - -- | MandrakeSoft USA | Sometimes you get what you want. | | http://www.mandrakesoft.com | Sometimes you get experience.| | http://www.mandrakelinux.com |--unknown origin | Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+d2OBlp7v05cW2woRAu0JAJ0eex1Fzs0A8mxOotf/aBK4CjjZ8ACfay4Q WFBU/lglc3iiHn9m2wjF6hY= =4Oi5 -END PGP SIGNATURE-
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 François Pons wrote: > Le lun 17/03/2003 à 21:55, Buchan Milne a écrit : > > This sounds me a problem of using obsoletes whereas a conflicts may be > better ? That's what I had originally. http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/samba/samba.spec.diff?r1=1.91&r2=1.92&f=h http://marc.theaimsgroup.com/?l=mandrake-cooker&w=2&r=1&s=samba+ldap+obsolete&q=b Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dzQ0rJK6UGDSBKcRAoojAJ91jkETYLtfJB53g0jvAPLfp9BjegCgmE9R DezKgdCXXO/k+smz7NTN+6I= =U9nt -END PGP SIGNATURE-
Re: [Cooker] urpmi features
On Tuesday 18 March 2003 14:04, François Pons wrote: > > - if a download was aborted use the part that is allready there and > > download the rest then > > This can automatically activated according to protocol used, typically > rsync allow that, whereas http or ftp protocol should be tried > differently, maybe by allowing continue download and download again on > error (only the beginning) if rpm is still inconsistent ? Yes this would be fine. ftp should allow that too in most cases. http I don't know > > > - if a server is to slow / not reachable, take the next > > Auto tune server before downloading ? yes , ping the server and take the one with the shortest round-trip ? I guess there are better solutions ;). The most imortant is that a not reachable server does not lead to an error. > > - urpmi.importmedia (mirror content to hd, build hdlist, add media) > > Yes, media management can be improved to create automatically > environment for updating media, spliting and others. > > This looks like mkcd or gendistrib features, maybe factorisation ? > gendistrib yes, but different media should be held on hd. I don't know what you mean with factorization :) If it mean to include gendistrib in urpm and deny it as standalone tool , yes. > > Don't know if it is meant by p2p magic-hdlist : a "click on a link to add > > media"/ urpmi://...hdlist.cz would maybe be fine too (Easy Urpmi thought > > one step further) > > I was thinking on synthesis containing all needed informations as an > extensions. Yes, then a mime-type for synthesis or something similar could lead to add this media. Sounds like the same in an other way > > > One other idea is nothing that can do urpmi: meta-packages for special > > purposes (like the groups during installation) > > Yes, I was thinking about it for 9.1, just need to use compssUsers file, > no added for 9.1 but great effectively. Extension of this with packages ? A group of people could work on a special topic. Lets say Linux Audio Workstation ;). They could define then such a special group in a package with needed packages description Make the group selection then in rpmdrake visable would top it. -- Regards Steffen counter.li.org : #296567. machine: 181800 vdr-box : 87 Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 21:55, Buchan Milne a écrit : > Can we have per-source 'skip.list's ? This has just shown up, since we run > samba-server-ldap (requires samba-common-ldap), which obsoletes and > provides samba-server (and vice versa) to allow users to move from one to > the other. All goes well however, until you get a security update for > samba, and it installs samba-server over samba-server-ldap and we have > downtime while I scp samba-server-ldap packages to the server and > add samba-server to the skip.list but now that I have newer ldap-enable > builds (will be on ftp.samba.org soon), I would have to take samba-server > out of the skip list again. This sounds me a problem of using obsoletes whereas a conflicts may be better ? François.
Re: [Cooker] urpmi features
Le mar 18/03/2003 à 00:08, Steffen Barszus a écrit : > - rsync for updates now that rsync is supported by urpmi (as well as https protocol), we can propose other mirror capabilities. > - if a download was aborted use the part that is allready there and download > the rest then This can automatically activated according to protocol used, typically rsync allow that, whereas http or ftp protocol should be tried differently, maybe by allowing continue download and download again on error (only the beginning) if rpm is still inconsistent ? > - if a server is to slow / not reachable, take the next Auto tune server before downloading ? > - ability to configure a path there packages go to if --noclean ability to use a different configuration file, which may authorize defining all other file to use. > - urpmi.importmedia (mirror content to hd, build hdlist, add media) Yes, media management can be improved to create automatically environment for updating media, spliting and others. This looks like mkcd or gendistrib features, maybe factorisation ? > Don't know if it is meant by p2p magic-hdlist : a "click on a link to add > media"/ urpmi://...hdlist.cz would maybe be fine too (Easy Urpmi thought one > step further) I was thinking on synthesis containing all needed informations as an extensions. > One other idea is nothing that can do urpmi: meta-packages for special > purposes (like the groups during installation) Yes, I was thinking about it for 9.1, just need to use compssUsers file, no added for 9.1 but great effectively. François.
Re: [Cooker] urpmi features
Todd Lyons <[EMAIL PROTECTED]> writes:
> increment_spec_version() {
[...]
> add_spec_changelog() {
[...]
for this stuff you can short it with emacs :
#!/bin/bash
# -*- Mode: shell-script -*-
# Chmouel Boudjnah <[EMAIL PROTECTED]>
name="Chmouel Boudjnah"
email="[EMAIL PROTECTED]"
increase=
opt=
while getopts i opt
do
case "$opt" in
i) increase="--eval (rpm-increase-release-tag)";;
esac
done
shift $((OPTIND - 1))
FILE=$1
CHANGE=$2
if [[ -z $FILE || -z $CHANGE ]];then
echo "Usage: FILE.SPEC CHANGELOG";
exit 1;
fi
tmp=/tmp/.add-changelog-emacs.$$
cat << EOF > $tmp
(setq user-full-name "$name")
(setq user-mail-address "$email")
EOF
emacs --no-site-file -batch -q -load $tmp \
--load "/usr/share/emacs/site-lisp/rpm-spec-mode.el" \
--eval "(find-file \"$FILE\")" \
$increase \
--eval "(rpm-add-change-log-entry \"$CHANGE\")" \
--eval "(write-file \"$FILE\")"
rm -f $tmp
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 20:08, Pascal Terjan a écrit : > I think it could at least be on urpmi.org (which is an independant > website which goal is to gather documentation about urpmi so it can be > more advertized). Just type urpmi in google and gather all documentation available and links, I tried it yesterday to gather opinions and idea about improvement. François.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 19:35, Pascal Terjan a écrit : > >>* possibility to use only one or several media, but less restricted. There > >>is an actual option to use only one source, --media, but what I would like > > FYI you can use more than one source in fact, separated by comma (,). > In fact the best improvment for urpmi would be documentation anad > advertising :-) FYI --media is documented this way using comma separated list, I agree there is lack of documentation, but user documentation is minimal and only devel documentation is lacking (especially for perl-URPM and urpm libraries). It will be taken as to be strongly needed, as perl-URPM reaches 1.0 release (only 0.81 currently, not far from now). François.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 19:55, Wesley J. Landaker a écrit : > urpmi then installs them all, supposedly in a nice correct order (I don't > doubt it's correct--I just haven't ever looked at how it does it currently No problem, this problem is solved by rpmlib which looks at PreReqs and Requires. > Instead, what urpmi could do is the following (and maybe it already does > some of this internally--if so, hey! less work!) Currently, urpmi use a non recursive algorithms without global optimization on requires to be fetched (to be fast enough, do not forget resolution algorithms is pure perl wchich is fast but interpreted). > Yeah, it's not going to get the perfectly smallest subsets when there are > cycles. But it in real practical use for RPMs it's *going* to generally > find lots of small subsets, even if they're not optimal, with very little > processing overhead. > This is what will be done, I didn't looked yet about a specific algorithm but I is effectively not very hard to solve. François.
Re: [Cooker] urpmi features
Le mar 18/03/2003 à 04:09, Robert L Martin a écrit : > Priority for sources. So that if two (or more) totaly same packages > exist in two (or more) sources you can set the priority so that the > package gets installed from the media with higher priority. For example > some prefere local sorces to have higher priority and some prefer some > FTP server for packages. This is currently linked to media priority, which sound enough for me. François.
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > An --info or whatever switch to get the description of an > uninstalled package, just as you get it with rpm --info packagename > when it's already installed. I totally support that ! Right now only rpmdrake can show you this type of information. And urpmf --description doesn't count, try to get the description for the package "bc" or "kernel" to get an idea... :-) I think it could be added to urpmq (instead of urpmi). Actually I'm looking for something like "apt-cache show". Aurélien - -- http://gauret.free.fr If you use enveloppes, why not encryption ? There are only 10 types of people in the world: those who understand binary and those who don't. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+dvMRp/o5vLhkpx0RAp0LAKDVsu7w5zXc1t4Vp7tz12h6dnLXhwCg483l CR7/Pj8tFq7OzvfUFHxXEpo= =rnM2 -END PGP SIGNATURE-
Re: [Cooker] urpmi features
I'm going to working on a an automatic rebuild capability (somewhat Gentoo-ish)... I've been thinking of doing this for a while, and the time for action draws near... ;o) Something like a urpmb command? One that will automatically fulfil the build requires (requiring temporary root elevation)... yeah... if the BuildRequires would be correct. Major hurdle here... A bit offtopic in this thread... Last week the idea came up to have your buildscripts post to bugzilla on failed packages. What do you think of it? This can be done. But the peice of software that does it would be declared a spammer in no time. At the moment, I don't think it's realistic. As long as we don't have a reliable solution for finding the real dependancies of the -devel packages, it's really no use. If we want to get it right I think we should focus on fixing that fundemental problem first. Those scripts do make it obvious what buildrequires are needed/missing, though even then it is time consuming to fix them, especially for hundreds of packages :-( True. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] urpmi features
yeah... if the BuildRequires would be correct. Major hurdle here...
Well, on the other hand, you will see immediatly if the buildrequires are
wrong...
Oh... You _really_ want to see this? Take a look at:
http://eijk.homelinux.org/build/cooker/i586/problem/
Those packages have a problem. Mostly BuildRequires stuff, sometimes
%%doc stuff, and the random other problem. Fixing BuildRequires does
not get priority at mdk... Finding the right BuildRequires is also very
difficult. See: http://eijk.homelinux.org/~stefan/slbd.html
Another thing I've been looking in lately is how dependancies on -devel
packages (don't) work. I posted this to the rpm-list at redhat:
A bit of history... when a peice of software was packaged the result
used to be one package, which included everything (libraries, binaries,
etc). The dependancies for this model worked quite fine, because it was
an all or nothing aproach. As distributions evolved things changed. When
I look at the current mandrake distribution, what used to be one package
is now split up into multiple packages.
* package containing binaries
* package containing libraries ( %{_libdir}/*.so.* )
* package containing -devel files ( %{_libdir}/*.a %{_libdir}/*.so
%{_includedir}/* )
I understand the rationale behind splitting up the packages. With the
"libpolicy" ( lib%{name}%{major} ) stuff it enables you to have multiple
versions of the library (often nice for compatability reasons) on the
system. Having separate -devel packages allows you to have them
installed or not (save up some diskspace) or compile for a certain
version of a lib.
Now what is missing is that the dependancy system has not evolved with
these changes. The dependancy system (automatically finding dependancies
on packages --> find-provides & find-requires) works fine for the
binaries and library packages, but has no effect on the -devel packages.
The work-around that has been to put the dependancy information for the
-devel packages in the .spec file.
Take as an example zlib and zlib-devel:
Requires for zlib:
$ rpm -qpR /mirrors/cooker/i586/Mandrake/RPMS/zlib1-1.1.4-4mdk.i586.rpm
/sbin/ldconfig
/sbin/ldconfig
*ld-linux.so.2found automatically
libc.so.6**found automatically*
* libc.so.6(GLIBC_2.0)** found automatically*
* libc.so.6(GLIBC_2.1)** found automatically*
* libc.so.6(GLIBC_2.1.3)** found automatically*
rpmlib(VersionedDependencies) <= 3.0.3-1 standard for all rpm
packages
rpmlib(PayloadFilesHavePrefix) <= 4.0-1standard for all rpm
packages
rpmlib(CompressedFileNames) <= 3.0.4-1 standard for all rpm
packages
*
*$ rpm -qp --provides
/mirrors/cooker/i586/Mandrake/RPMS/zlib1-1.1.4-4mdk.i586.rpm
libz = 1.1.4-4mdkin .spec file
libz1 = 1.1.4-4mdk in .spec file
zlib = 1.1.4-4mdkin .spec file
* libz.so.1** found automatically*
zlib1 = 1.1.4-4mdk in .spec file
%package -n %{lib_name}
Summary: The zlib compression and decompression library
Group: System/Libraries
Obsoletes: libz, libz1, %{name}
Provides: libz = %{version}-%{release} libz1 = %{version}-%{release}
%{name} = %{version}-%{release}
$ rpm -qpR
/mirrors/cooker/i586/Mandrake/RPMS/zlib1-devel-1.1.4-4mdk.i586.rpm
* * zlib1 = 1.1.4-4mdkin .spec file
rpmlib(VersionedDependencies) <= 3.0.3-1 standard for all rpm
packages
rpmlib(PayloadFilesHavePrefix) <= 4.0-1 standard for all rpm
packages
rpmlib(CompressedFileNames) <= 3.0.4-1standard for all rpm
packages
$ rpm -qp --provides
/mirrors/cooker/i586/Mandrake/RPMS/zlib1-devel-1.1.4-4mdk.i586.rpm
libz-devel = 1.1.4-4mdk in .spec file
libz1-devel = 1.1.4-4mdk in .spec file
zlib-devel = 1.1.4-4mdk in .spec file
zlib1-devel = 1.1.4-4mdk in .spec file
%package -n %{lib_name}-devel
Summary: Header files and libraries for developing apps which will use zlib
Group: Development/C
Requires: %{lib_name} = %{version}-%{release}
Obsoletes: libz1-devel, libz-devel, zlib-devel
Provides: libz-devel = %{version}-%{release} libz1-devel =
%{version}-%{release} %{name}-devel = %{version}-%{release}
All the dependancy information contained in the zlib-devel package
originates from the .spec file. IMHO this is a hack, intended to solve
the more simple issue --> make sure that zlib is installed when
zlib-devel is needed. Zlib is a small, simple package, with more complex
packages this was of providing dependancy information does not scale.
and for the following reason:
* relationships between the files in the -devel package and other
-devel packages are not automatically found.
It should be po
Re: [Cooker] urpmi features
On Tue 2003-03-18 at 09:10:38 +1200, [EMAIL PROTECTED] wrote: > Urpmi needs to be able to resume if a disconnection occurs and use rsync > to get the required differences between packages only IMHO. This would > include Cooker packages. Do you mean something different that using an rsync-enabled source and running "urpmi --noclean?". For any rsync solution you need an rsync-enabled mirror anyhow and the second option you already have. I am missing something? Bye, Benjamin. pgp0.pgp Description: PGP signature
Re: [Cooker] urpmi features
Priority for sources. So that if two (or more) totaly same packages exist in two (or more) sources you can set the priority so that the package gets installed from the media with higher priority. For example some prefere local sorces to have higher priority and some prefer some FTP server for packages. i would break it down further into |local fixed | local removeable| lan | Net Close |Net Far| example given the rpm sempterfi3.14.16.i586.rpm If you pick the rpm from a list and its on a local mount point /usr/rpmcache/ then it gets installed from there EVEN IF THE LIST ITEM IS from say http://www.paris.fr. but if the remote server has a dependent rpm like unbacking4.32.16.i586.rpm then that gets pulled from the paris.fr server. Speaking of which how does urpmi handle exact same file trees?
Re: [Cooker] urpmi features
On Mon, 2003-03-17 at 09:53, Vox wrote: > This time François Pons <[EMAIL PROTECTED]> > becomes daring and writes: > > > Possible features of urpmi for next release : > > > > * virtual medium (no need to update explicitely, only with synthesis ?). > > * delay before accepting using a package from a medium (cooker) > > * always ask confirmation if fuzzy search is used (even for 1 package) > > * on the fly sorting of media (according to regex like > > file,rsync,ftp,http) > > * urpm centralized tools, as well as perl-URPM managing media. > > * p2p urpmi database (export database as magic synthesis) > > * -h by default for urpmi.addmedia > > * do install of package by groups which are shorter as possible (apt-get > > like) > > * allow file conflicts error to be handled by recovering errors and try > > again. > > * conflicts, provides and requires tag added for global rpm behaviour in > > order to allow broken dependencies to be not resolved or to avoid > > removing important package (generalize basesystem) > > > > Any other idea are wellcome. > > An --info or whatever switch to get the description of an > uninstalled package, just as you get it with rpm --info packagename > when it's already installed. Vox, Do you mean like # rpm -qip http://redhat.secsup.org/redhat/linux/7.3/en/os/i386/RedHat/RPMS/4Suite-0.11.1-8.i386.rpm (try it it works) I chose this rh rpm because I knew it wouldn't be installed on your MDK box. *grin* (btw the switch is q as in query ip just in case of font problem) James > > And the build-from-source thing that Levi mentioned...specially > useful if urpmi "remembers" what has been built from source and what > has been installed from binaries, and updates accordingly...that > would absolutely rule :) > > Vox
Re: [Cooker] urpmi features
On Mon, 2003-03-17 at 11:01, Wesley J. Landaker wrote: > Apparently, Todd Lyons recently wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : > >> > > >> I'm going to working on a an automatic rebuild capability (somewhat > >> Gentoo-ish)... I've been thinking of doing this for a while, and the > >> time for action draws near... ;o) > > > > Something like a urpmb command? One that will automatically fulfil the > > build requires (requiring temporary root elevation)... > > This would be exceptionally awesome. =) > > If this were to work through upgrades, though, it would be nice if urpmi > would remember what packages had been urpmb, so they they would also be > recompiled on an upgrade. > > For instance, if A depends on B, which depends on C, and I just urpmb B, > if later versions of A B and C all are new, and get selected from an urpmi > --auto-select (or maybe this behavior would only happen with urpmb > --auto-select, I don't know) it would install C, build+install B, then > install A. > > I've been doing this kind of thing a lot by hand. It would be awesome if > it was supported by urpmi tools. Would be even neater if it allowed you subsitute rpms... IE it can't find foo_bar-1.0 but you have foo-bar-1.0 (different distro's) it could come back and ask...Hey you don't have this and I can't find it... what do I do 1. use a subsitute (at your own risk good luck) 2. abort. Would be best if I could build rpms that had an "or" capability in BuildRequries in the spec sheet, but this might be a usable work around. James > > Wes > > >
Re: [Cooker] urpmi features
On Mon, 2003-03-17 at 08:51, Jean-Michel Dault wrote: > Le lun 17/03/2003 à 13:37, Eric Fernandez a écrit : > > Good ideas Francois. > > Here are mines : > > * possibility to ignore one or several sources > > I totally support this one. Having a --excludemedia option would be nice > when you want, for example, to upgrade to the latest cooker, but don't > want to upgrade to the latest contribs. (Like with apache/apache2, > gd/gd2, horde/horde2). In a sense doesn't it do this already.. if you open the software sources menu the uncheck a source and click save and quit. it will put an ignore tag on this item in /etc/urpmi/urpmi.cfg. This source is still configured and can be re-activated any time you'd like but for the moment urpmi -a and urpmi xx will not access this media. I use it all the time for boxes so I don't have to carry disks with me everywhere I go. James > > > * possibility to use only one or several media, but less restricted. There > > is an actual option to use only one source, --media, but what I would like > > is an option that would use only one source, but would solve and download > > dependencies if any from other sources anyway. > > Jean-Michel > >
Re: [Cooker] urpmi features
On Tue, 18 Mar 2003 00:52:04 +0100 Stefan van der Eijk <[EMAIL PROTECTED]> wrote: > >>Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : > >>>I'm going to working on a an automatic rebuild capability (somewhat > >>>Gentoo-ish)... I've been thinking of doing this for a while, and the > >>>time for action draws near... ;o) > >>> > >>Something like a urpmb command? One that will automatically fulfil the > >>build requires (requiring temporary root elevation)... > > > yeah... if the BuildRequires would be correct. Major hurdle here... A bit offtopic in this thread... Last week the idea came up to have your buildscripts post to bugzilla on failed packages. What do you think of it? Those scripts do make it obvious what buildrequires are needed/missing, though even then it is time consuming to fix them, especially for hundreds of packages :-( -- Marcel Pol
Re: [Cooker] urpmi features
Entête en cours de reécriture, merci de patienter en lisant la réponse au mail de Stefan van der Eijk, à Mardi 18 Mars 2003 00:52 > yeah... if the BuildRequires would be correct. Major hurdle here... Well, on the other hand, you will see immediatly if the buildrequires are wrong... -- Michaël Scherer
Re: [Cooker] urpmi features
On Tue, 18 Mar 2003 09:10:38 +1200, "Jason Greenwood" <[EMAIL PROTECTED]> said: > Urpmi needs to be able to resume if a disconnection occurs and use rsync > to get the required differences between packages only IMHO. This would > include Cooker packages. > > Cheers > > Jason > Man that would be useful. -- http://www.fastmail.fm - Access all of your messages and folders wherever you are
Re: [Cooker] urpmi features
Wesley J. Landaker wrote: Apparently, Todd Lyons recently wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : I'm going to working on a an automatic rebuild capability (somewhat Gentoo-ish)... I've been thinking of doing this for a while, and the time for action draws near... ;o) Something like a urpmb command? One that will automatically fulfil the build requires (requiring temporary root elevation)... This would be exceptionally awesome. =) yeah... if the BuildRequires would be correct. Major hurdle here... Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] urpmi features
François Pons wrote: Possible features of urpmi for next release : * virtual medium (no need to update explicitely, only with synthesis ?). * delay before accepting using a package from a medium (cooker) * always ask confirmation if fuzzy search is used (even for 1 package) * on the fly sorting of media (according to regex like file,rsync,ftp,http) * urpm centralized tools, as well as perl-URPM managing media. * p2p urpmi database (export database as magic synthesis) * -h by default for urpmi.addmedia * do install of package by groups which are shorter as possible (apt-get like) * allow file conflicts error to be handled by recovering errors and try again. * conflicts, provides and requires tag added for global rpm behaviour in order to allow broken dependencies to be not resolved or to avoid removing important package (generalize basesystem) Any other idea are wellcome. * rpm 4.1 support (for those poor souls forced to work with RH8.X) * extra switch for urpmq. When calculating dependancies, take the package which is installed / and continue to climb down the dependancy tree. for example: "urpmq -dp basesystem" in the resulting list you'll find multiple packages that satisfy a dependancy for basesystem. These packages are printed like: "vim-enhanced|vim-minimal|vim-X11" I'd like a switch that will pick the package which is installed on the system (vim-minimal in my case now) and add the packages which are dependant on vim-minimal to the list. Effectively run urpmq -dp against vim-minimal. This is usefull for "cleanup scripts" and BuildRequires calculations. Out of scope for urpm*, but in scope for rpm: * automatic dependancy system (find-provides, find-requires) that can compute dependancies for -devel packages. Currently this is all done manually and is very inaccurate. Make a find-[provides|requires] script that can search through header files (and other stuff in -devel packages) and sort out the dependancies with other -devel packages. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] urpmi features
> Help how do I get off this mailing lis http://www.mandrakelinux.com/en/fdevlists.php3 -- http://www.fastmail.fm - mmm... fastmail
Re: [Cooker] urpmi features
* possibility to use only one or several media, but less restricted. There is an actual option to use only one source, --media, but what I would like FYI you can use more than one source in fact, separated by comma (,). I confirm this. I'm using this in my rebuilding scripts, with interesting results. When rebuilding packages for cooker, contrib and plf I use the following media: cooker = cooker contrib = cooker,contrib plf = cooker,contrib,plf works great! Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] urpmi features
On Monday 17 March 2003 22:50, [EMAIL PROTECTED] wrote: > Quoting Jason Greenwood <[EMAIL PROTECTED]>: > > It would also be great if dialog box came up before downloading packages > > > > that asked if you wanted to keep the rpm's on your system after > > download. It could also say somehting like, "packages will be held in > > /var/cache/urpmi/rpms until you delete them" > > There is already that option :) > --noclean > > Eric Maybe like it is in mplayer: a config-file there you can put in your default options ? To come to my favorites in this discussion: - rsync for updates - if a download was aborted use the part that is allready there and download the rest then - if a server is to slow / not reachable, take the next - ability to configure a path there packages go to if --noclean - urpmi.importmedia (mirror content to hd, build hdlist, add media) Don't know if it is meant by p2p magic-hdlist : a "click on a link to add media"/ urpmi://...hdlist.cz would maybe be fine too (Easy Urpmi thought one step further) One other idea is nothing that can do urpmi: meta-packages for special purposes (like the groups during installation) -- Regards Steffen counter.li.org : #296567. machine: 181800 vdr-box : 87 Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
Re: [Cooker] urpmi features
On Monday 17 March 2003 02:42 pm, Jesse Wagner wrote: Help how do I get off this mailing lis > On 17 Mar 2003 18:35:02 +0100, "François Pons" <[EMAIL PROTECTED]> > > said: > > Possible features of urpmi for next release : > > > > * virtual medium (no need to update explicitely, only with synthesis ?). > > * delay before accepting using a package from a medium (cooker) > > * always ask confirmation if fuzzy search is used (even for 1 package) > > * on the fly sorting of media (according to regex like > > file,rsync,ftp,http) > > * urpm centralized tools, as well as perl-URPM managing media. > > * p2p urpmi database (export database as magic synthesis) > > * -h by default for urpmi.addmedia > > * do install of package by groups which are shorter as possible (apt-get > > like) > > * allow file conflicts error to be handled by recovering errors and try > > again. > > * conflicts, provides and requires tag added for global rpm behaviour in > > order to allow broken dependencies to be not resolved or to avoid > > removing important package (generalize basesystem) > > > > Any other idea are wellcome. > > > > François. > > * Look in current folder for deps
Re: [Cooker] urpmi features
Quoting Jason Greenwood <[EMAIL PROTECTED]>: > Yeah, it's hard to keep up with the names of MDK software sometimes, is > > it Graphical URPMI, rpmdrake, software manager, what?? Is it MCC or > Mandrake Control Center, drakxtools or drakconf?? :-D yep ! > > Plus, there are many "drak" tools available from the command line that > > are either not present in the MCC or are hard to find. > > All my point was, was that there are many functionalities of URPMI > (indeed many Mandrake config/admin utils) not available graphically. If > > these could be made available via a GUI then more newbies would > experience their power and advertise it via word of mouth. I agree 100% Jason ! I think that even for newbies, GUI has not to be necessarily simple. Advanced options may be optionnaly displayed with a button, but making these powerful options accessible to everyone is important. Suse rpm manager is complex, but nicely done (colour codes, for example). If a GUI is logical and well designed, it may be full of options. Eric
Re: [Cooker] urpmi features
On 17 Mar 2003 18:35:02 +0100, "François Pons" <[EMAIL PROTECTED]> said: > Possible features of urpmi for next release : > > * virtual medium (no need to update explicitely, only with synthesis ?). > * delay before accepting using a package from a medium (cooker) > * always ask confirmation if fuzzy search is used (even for 1 package) > * on the fly sorting of media (according to regex like > file,rsync,ftp,http) > * urpm centralized tools, as well as perl-URPM managing media. > * p2p urpmi database (export database as magic synthesis) > * -h by default for urpmi.addmedia > * do install of package by groups which are shorter as possible (apt-get > like) > * allow file conflicts error to be handled by recovering errors and try > again. > * conflicts, provides and requires tag added for global rpm behaviour in > order to allow broken dependencies to be not resolved or to avoid > removing important package (generalize basesystem) > > Any other idea are wellcome. > > François. > * Look in current folder for deps -- http://www.fastmail.fm - Send your email first class
Re: [Cooker] urpmi features
Yeah, it's hard to keep up with the names of MDK software sometimes, is it Graphical URPMI, rpmdrake, software manager, what?? Is it MCC or Mandrake Control Center, drakxtools or drakconf?? Plus, there are many "drak" tools available from the command line that are either not present in the MCC or are hard to find. All my point was, was that there are many functionalities of URPMI (indeed many Mandrake config/admin utils) not available graphically. If these could be made available via a GUI then more newbies would experience their power and advertise it via word of mouth. Cheers Jason [EMAIL PROTECTED] wrote: Quoting Jason Greenwood <[EMAIL PROTECTED]>: ok, where is that option in the gui then?? I KNOW what it can do from the command line, I mean that these great features need to be in the GUI. Cheers Jason You're right, misread it. But this would be a rpmdrake feature, not urpmi ;) BTW, yes it would be nice to have an advanced mode in the GUI to have access to that kind of options. Cheers Eric
Re: [Cooker] urpmi features
Quoting Jason Greenwood <[EMAIL PROTECTED]>: > ok, where is that option in the gui then?? > > I KNOW what it can do from the command line, I mean that these great > features need to be in the GUI. > > Cheers > > Jason You're right, misread it. But this would be a rpmdrake feature, not urpmi ;) BTW, yes it would be nice to have an advanced mode in the GUI to have access to that kind of options. Cheers Eric
Re: [Cooker] urpmi features
ok, where is that option in the gui then?? I KNOW what it can do from the command line, I mean that these great features need to be in the GUI. Cheers Jason [EMAIL PROTECTED] wrote: Quoting Jason Greenwood <[EMAIL PROTECTED]>: It would also be great if dialog box came up before downloading packages that asked if you wanted to keep the rpm's on your system after download. It could also say somehting like, "packages will be held in /var/cache/urpmi/rpms until you delete them" There is already that option :) --noclean Eric
Re: [Cooker] urpmi features
Quoting Jason Greenwood <[EMAIL PROTECTED]>: > It would also be great if dialog box came up before downloading packages > > that asked if you wanted to keep the rpm's on your system after > download. It could also say somehting like, "packages will be held in > /var/cache/urpmi/rpms until you delete them" There is already that option :) --noclean Eric
Re: [Cooker] urpmi features
It would also be great if dialog box came up before downloading packages that asked if you wanted to keep the rpm's on your system after download. It could also say somehting like, "packages will be held in /var/cache/urpmi/rpms until you delete them" Jason Greenwood wrote: Urpmi needs to be able to resume if a disconnection occurs and use rsync to get the required differences between packages only IMHO. This would include Cooker packages. Cheers Jason Buchan Milne wrote: On Mon, 17 Mar 2003, [ISO-8859-1] François Pons wrote: Possible features of urpmi for next release : * virtual medium (no need to update explicitely, only with synthesis ?). * delay before accepting using a package from a medium (cooker) * always ask confirmation if fuzzy search is used (even for 1 package) * on the fly sorting of media (according to regex like file,rsync,ftp,http) * urpm centralized tools, as well as perl-URPM managing media. * p2p urpmi database (export database as magic synthesis) * -h by default for urpmi.addmedia * do install of package by groups which are shorter as possible (apt-get like) * allow file conflicts error to be handled by recovering errors and try again. * conflicts, provides and requires tag added for global rpm behaviour in order to allow broken dependencies to be not resolved or to avoid removing important package (generalize basesystem) Any other idea are wellcome. Can we have per-source 'skip.list's ? This has just shown up, since we run samba-server-ldap (requires samba-common-ldap), which obsoletes and provides samba-server (and vice versa) to allow users to move from one to the other. All goes well however, until you get a security update for samba, and it installs samba-server over samba-server-ldap and we have downtime while I scp samba-server-ldap packages to the server and add samba-server to the skip.list but now that I have newer ldap-enable builds (will be on ftp.samba.org soon), I would have to take samba-server out of the skip list again. I think this would be useful for people using (for example) PLF sources? You could put 'mplayer' in /etc/urpmi/skip-cooker.list (for cooker source). Regards, Buchan
Re: [Cooker] urpmi features
Urpmi needs to be able to resume if a disconnection occurs and use rsync to get the required differences between packages only IMHO. This would include Cooker packages. Cheers Jason Buchan Milne wrote: On Mon, 17 Mar 2003, [ISO-8859-1] François Pons wrote: Possible features of urpmi for next release : * virtual medium (no need to update explicitely, only with synthesis ?). * delay before accepting using a package from a medium (cooker) * always ask confirmation if fuzzy search is used (even for 1 package) * on the fly sorting of media (according to regex like file,rsync,ftp,http) * urpm centralized tools, as well as perl-URPM managing media. * p2p urpmi database (export database as magic synthesis) * -h by default for urpmi.addmedia * do install of package by groups which are shorter as possible (apt-get like) * allow file conflicts error to be handled by recovering errors and try again. * conflicts, provides and requires tag added for global rpm behaviour in order to allow broken dependencies to be not resolved or to avoid removing important package (generalize basesystem) Any other idea are wellcome. Can we have per-source 'skip.list's ? This has just shown up, since we run samba-server-ldap (requires samba-common-ldap), which obsoletes and provides samba-server (and vice versa) to allow users to move from one to the other. All goes well however, until you get a security update for samba, and it installs samba-server over samba-server-ldap and we have downtime while I scp samba-server-ldap packages to the server and add samba-server to the skip.list but now that I have newer ldap-enable builds (will be on ftp.samba.org soon), I would have to take samba-server out of the skip list again. I think this would be useful for people using (for example) PLF sources? You could put 'mplayer' in /etc/urpmi/skip-cooker.list (for cooker source). Regards, Buchan
Re: [Cooker] urpmi features
On Mon, 17 Mar 2003, [ISO-8859-1] François Pons wrote: > Possible features of urpmi for next release : > > * virtual medium (no need to update explicitely, only with synthesis ?). > * delay before accepting using a package from a medium (cooker) > * always ask confirmation if fuzzy search is used (even for 1 package) > * on the fly sorting of media (according to regex like > file,rsync,ftp,http) > * urpm centralized tools, as well as perl-URPM managing media. > * p2p urpmi database (export database as magic synthesis) > * -h by default for urpmi.addmedia > * do install of package by groups which are shorter as possible (apt-get > like) > * allow file conflicts error to be handled by recovering errors and try > again. > * conflicts, provides and requires tag added for global rpm behaviour in > order to allow broken dependencies to be not resolved or to avoid > removing important package (generalize basesystem) > > Any other idea are wellcome. > Can we have per-source 'skip.list's ? This has just shown up, since we run samba-server-ldap (requires samba-common-ldap), which obsoletes and provides samba-server (and vice versa) to allow users to move from one to the other. All goes well however, until you get a security update for samba, and it installs samba-server over samba-server-ldap and we have downtime while I scp samba-server-ldap packages to the server and add samba-server to the skip.list but now that I have newer ldap-enable builds (will be on ftp.samba.org soon), I would have to take samba-server out of the skip list again. I think this would be useful for people using (for example) PLF sources? You could put 'mplayer' in /etc/urpmi/skip-cooker.list (for cooker source). Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] urpmi features
On Mon, 17 Mar 2003, Todd Lyons wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : > > > > > I'm going to working on a an automatic rebuild capability (somewhat > > Gentoo-ish)... I've been thinking of doing this for a while, and the > > time for action draws near... ;o) > > Something like a urpmb command? One that will automatically fulfil the > build requires (requiring temporary root elevation)... > via sudo of course ... And, ideally we want it to be able to build packages from Mandrakesoft CVS (so if you have -1mdk, you don't need to download the whole source tarballs to build -2mdk). If it could fetch source tarballs from the original locations too ... or in combination with a cvs snapshot of the original source ... This is not so difficult really, and would be ultra-cool. I have some bash scripts which I use to do this kind of thing ... -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wesley J. Landaker wrote on Mon, Mar 17, 2003 at 12:01:44PM -0700 :
>
> I've been doing this kind of thing a lot by hand. It would be awesome if
> it was supported by urpmi tools.
Agreed.
Kind of similar, I have a script that I use to maintain some personal
CVS rpms that I use (such as mutt). Here's the script that I use to do
it.
#!/bin/bash
# Set environment variables here. Their function should be obvious.
CVSLOCATION="-d :pserver:[EMAIL PROTECTED]:/cvsroot/slicker"
PROG="slicker"
VER="0.1"
SPECFILE="$HOME/RPM/SPECS/$PROG.spec"
UPLOADUSER=todd
UPLOADHOST=www.mrball.net
UPLOADDIR=/var/www/vhosts/downloads.mrball.net
increment_spec_version() {
# Set extension. Would normally be mdk, but set it to your initials
# so that it's clear that it's not an official Mandrake RPM.
EXT=tal
VERSION=$(awk '$0 ~ /%define release/ {print $3}' ${SPECFILE})
TARG=$(echo $VERSION | sed 's/0\.cvs\.//' | sed "s/${EXT}//")
LASTTARG=$(( $TARG - 1 ))
TARG=$(( $TARG + 1 ))
LASTVER="0.cvs.${LASTTARG}${EXT}"
NEWVER="0.cvs.${TARG}${EXT}"
echo "Using $NEWVER as current release version."
perl -pi -e "s/%define release $VERSION/%define release $NEWVER/" \
$SPECFILE
unset EXT
}
add_spec_changelog() {
LINE1="* $(date +"%a %b %d %Y") Todd Lyons <[EMAIL PROTECTED]> $VER-$NEWVER"
LINE2="- Updated cvs snapshot"
perl -we "open (SPEC, \"${SPECFILE}\");
while () {
print $1;
/%changelog/ && print \"$LINE1\n$LINE2\n\n\";
}
close SPEC;" > $SPECFILE.$NEWVER
mv -f $SPECFILE $SPECFILE.$VERSION
mv -f $SPECFILE.$NEWVER $SPECFILE
[ -e $SPECFILE.$LASTVER ] && rm -f $SPECFILE.$LASTVER
}
echo
echo "Password is blank"
echo
unset GOTTEN
cd ~/src
[ ! -d $PROG ] \
&& [ -d $PROG-$VER ] \
&& mv $PROG-$VER $PROG \
&& GOTTEN=yes
[ ! -d ${PROG} ] \
&& mkdir $PROG
cvs $CVSLOCATION login
if [ -z $GOTTEN ]; then
cvs -z3 $CVSLOCATION co $PROG
else
cvs -z3 $CVSLOCATION update $PROG
fi
cvs $CVSLOCATION logout
cd $PROG
make distclean
cd ..
mv $PROG $PROG-$VER
tar -jcvf $PROG-$VER.tar.bz2 $PROG-$VER
mv -f $PROG-$VER.tar.bz2 ~/RPM/SOURCES
echo
echo -n "Build new $PROG? (y/n) "
read answer
case "$answer" in
y*|Y*)
increment_spec_version
add_spec_changelog
rpm -ba $SPECFILE
;;
*)
exit 0
;;
esac
# echo "Exiting before upload" && exit 0
unset answer
echo
echo -n "Upload to server? (y/n) "
read answer
case "$answer" in
y*|Y*)
NEWRPM=$(ls ~/RPM/RPMS/i586/$PROG-$VER* | tail -n 1)
NEWSRPM=$(ls ~/RPM/SRPMS/$PROG-$VER* | tail -n 1)
scp $NEWRPM \
[EMAIL PROTECTED]:$UPLOADDIR/Mandrake/9.0/RPMS
scp $NEWSRPM \
[EMAIL PROTECTED]:$UPLOADDIR/Mandrake/9.0/SRPMS
;;
*)
exit 0
;;
esac
- --
...and I will strike down upon thee with great vengeance and furious
anger, those who attempt to poison and destroy my binaries, and you
will know my name is root, when I lay my vengeance upon thee.
Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+diJQlp7v05cW2woRAk7zAKCvyp9GxZ2vBIYojBdxrXZF67P5xQCdGMeB
woYjQ23H5hRcNG24j3Fam3Q=
=7Nae
-END PGP SIGNATURE-
Re: [Cooker] urpmi features
Guillaume Rousse wrote: Le Lundi 17 Mars 2003 19:56, Eric Fernandez a écrit : Here is the English version (shorter than the French one but ok) http://rage3d.com/board/showthread.php?s=&threadid=33668481 One link again for urpmi.org However, they are both forum article, which is not the best place for standalone documents. What about moving them to actual stable urls ? If you agree to put it on your site, I would be glad. My web space may be terminated in 6 months (maybe I will move from UK to another country, don't even know where :) Eric
Re: [Cooker] urpmi features
Guillaume Rousse wrote: Le Lundi 17 Mars 2003 19:52, Eric Fernandez a écrit : In fact the best improvment for urpmi would be documentation anad advertising :-) Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is in French, but I have also an english translation. A lot of newbies gave me good feedback. It is here : If you want, you can use it to include it in the documentation, I shall put it under FDL if necessary. It is here : http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&c a che=cache&sondage=&owntopic=&p=1&trash=&subcat= Should be linked from urpmi.org. Thorpe ? Hi ! I was talking about you !! Do you want me to do a HTML version ? The problem of the forum is that this thread goes up and down. But if you want to put it as a link, this would be fine :) If you want me to do something about it, feel free to contact me. A graphical tutorial, like the one in http://trylinuxsd.com would be perfect too. For a command-line tool ? It would be a separate part, using the rpmdrake frontend. Eric
Re: [Cooker] urpmi features
Le Lundi 17 Mars 2003 19:56, Eric Fernandez a écrit : > Here is the English version (shorter than the French one but ok) > http://rage3d.com/board/showthread.php?s=&threadid=33668481 One link again for urpmi.org However, they are both forum article, which is not the best place for standalone documents. What about moving them to actual stable urls ? -- When you finally buy enough memory, you will not have enough disk space. -- Murphy's Computer Laws n°3
Re: [Cooker] urpmi features
Pascal Terjan wrote: Eric Fernandez wrote: Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is in French, but I have also an english translation. A lot of newbies gave me good feedback. It is here : If you want, you can use it to include it in the documentation, I shall put it under FDL if necessary. It is here : http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&ca che=cache&sondage=&owntopic=&p=1&trash=&subcat= Looks fine. I think it could at least be on urpmi.org (which is an independant website which goal is to gather documentation about urpmi so it can be more advertized). Thanks. I aimed at the newbies who always asked the same questions, or wanted to know how to compile a software that was already packaged (even if compiling is fun, but you cannot explain that to someone who want to play within 1 minute !) I will contact Guillaume Rousse to see if he would be interested to put it on the site, and to have a PDF version. Eric
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Lyons wrote on Mon, Mar 17, 2003 at 10:41:44AM -0800 : > > Kind of combining these two, I think it can be combined into one. At > the commandline, you can only specify one source. If you specify Sorry. I was wrong Wrong WRONG. As Francois pointed out, you can use a comma to seperate them. My apologies all for disseminating false information. Blue skies... Todd - -- MandrakeSoft USA http://www.mandrakesoft.com Easy things should be easy, and hard things should be possible. --Larry Wall Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+dh/Mlp7v05cW2woRAtZ+AJoDoThZPVFkGVmVb03PPKjZSEJcXQCeKFkv DwdHwt/ybImoeyflaySmN4A= =bP+Z -END PGP SIGNATURE-
Re: [Cooker] urpmi features
Le Lundi 17 Mars 2003 19:52, Eric Fernandez a écrit : > > In fact the best improvment for urpmi would be documentation anad > > advertising :-) > > Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is > in French, but I have also an english translation. A lot of newbies gave me > good feedback. It is here : > If you want, you can use it to include it in the documentation, I shall put > it under FDL if necessary. > It is here : > http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&c >a che=cache&sondage=&owntopic=&p=1&trash=&subcat= Should be linked from urpmi.org. Thorpe ? > If you want me to do something about it, feel free to contact me. > A graphical tutorial, like the one in http://trylinuxsd.com would be > perfect too. For a command-line tool ? -- When you finally buy enough memory, you will not have enough disk space. -- Murphy's Computer Laws n°3
Re: [Cooker] urpmi features
Eric Fernandez wrote: Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is in French, but I have also an english translation. A lot of newbies gave me good feedback. It is here : If you want, you can use it to include it in the documentation, I shall put it under FDL if necessary. It is here : http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&ca che=cache&sondage=&owntopic=&p=1&trash=&subcat= Looks fine. I think it could at least be on urpmi.org (which is an independant website which goal is to gather documentation about urpmi so it can be more advertized).
Re: [Cooker] urpmi features
Eric Fernandez wrote: You mean it would be illegal to even put the mirrors list of PLF in the distro ? Not illegal but I think Mandrakesoft does not want to know that PLF exists and does not want to have any link with it. (And I can understand that).
Re: [Cooker] urpmi features
Apparently, Todd Lyons recently wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : >> > >> I'm going to working on a an automatic rebuild capability (somewhat >> Gentoo-ish)... I've been thinking of doing this for a while, and the >> time for action draws near... ;o) > > Something like a urpmb command? One that will automatically fulfil the > build requires (requiring temporary root elevation)... This would be exceptionally awesome. =) If this were to work through upgrades, though, it would be nice if urpmi would remember what packages had been urpmb, so they they would also be recompiled on an upgrade. For instance, if A depends on B, which depends on C, and I just urpmb B, if later versions of A B and C all are new, and get selected from an urpmi --auto-select (or maybe this behavior would only happen with urpmb --auto-select, I don't know) it would install C, build+install B, then install A. I've been doing this kind of thing a lot by hand. It would be awesome if it was supported by urpmi tools. Wes
Re: [Cooker] urpmi features
> Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is in > French, but I have also an english translation. A lot of newbies gave me > good feedback. It is here : > If you want, you can use it to include it in the documentation, I shall put > it under FDL if necessary. > It is here : > http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&ca > che=cache&sondage=&owntopic=&p=1&trash=&subcat= > > If you want me to do something about it, feel free to contact me. > A graphical tutorial, like the one in http://trylinuxsd.com would be perfect > too. > > Here is the English version (shorter than the French one but ok) http://rage3d.com/board/showthread.php?s=&threadid=33668481 Eric
Re: [Cooker] urpmi features
Apparently, Pascal Terjan recently wrote: >> * do install of package by groups which are shorter as possible >> (apt-get >> like) > Would be nice. Good luck for an optimized algorithm :) Okay, just a little discussion on this, because I really would like this as well! =) Anyway, it's not really that *much* harder than what "make" does; you just build then traverse a DAG... just... in urpmi's case... it's not always a DAG (sometimes there ARE cycles). But that's okay. For instance, say I want to installed package "A". Say the dependancies look like this: Package: Dependancies A: B C D B: C E F C: D: F B E: F: B (oh no, a loop!) So, I go: $ urpmi A Right now it says, ah, A needs B, C, and D. B needs C (already in the list) E, and F. C doesn't need anything; great! D needs F and B (oh! already in the list, too). E needs nothing; good. F needs B (it's already in the list; yeah, it's going to be a loop, but self-consistancy is maintained, and everyone is happy); sweet! The following packages are going to be installed: A B C D E F (or whatever order it shows in) urpmi then installs them all, supposedly in a nice correct order (I don't doubt it's correct--I just haven't ever looked at how it does it currently ;). Instead, what urpmi could do is the following (and maybe it already does some of this internally--if so, hey! less work!) $ urpmi A urpmi builds a nice DAG like this by discarding edges for any reference that goes to a node we've already seen. A -> B A -> C A -> D B -> C (discarded) B -> E B -> F D -> F (discarded) D -> B F -> B (discarded) Now use djikstra's longest-path or something similar (there are more advanced algorithms); and you get the following (possible) ordering: C E B D F A Now, urpmi can run, conceptually (no new dependancy calculation is necessary) the following: urpmi C C [100%] urpmi E E [100%] urpmi B B [100%] urpmi D F [100%] D [100%] urpmi F (everything is already installed) urpmi A A [100%] Yeah, it's not going to get the perfectly smallest subsets when there are cycles. But it in real practical use for RPMs it's *going* to generally find lots of small subsets, even if they're not optimal, with very little processing overhead. Wes
Re: [Cooker] urpmi features
FYI you can use more than one source in fact, separated by comma (,). François. I know, but it would be unnecessary to launch urpmi again with the new names of the needed sources. It would solve automatically the dependances, wherever they are (but choosing the wanted rpm in the specified --media source only). Eric
Re: [Cooker] urpmi features
- Original Message - From: "Pascal Terjan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 17, 2003 6:35 PM Subject: Re: [Cooker] urpmi features > François Pons wrote: > > Le lun 17/03/2003 à 18:37, Eric Fernandez a écrit : > > > > > >>* possibility to use only one or several media, but less restricted. There > >>is an actual option to use only one source, --media, but what I would like > > > > > > FYI you can use more than one source in fact, separated by comma (,). > > > > François. > > In fact the best improvment for urpmi would be documentation anad > advertising :-) > > Exact, 100% agreed. I wrote a doc about urpmi in Hardware.fr forum, it is in French, but I have also an english translation. A lot of newbies gave me good feedback. It is here : If you want, you can use it to include it in the documentation, I shall put it under FDL if necessary. It is here : http://forum.hardware.fr/forum2.php3?post=20457&cat=11&config=&interface=&ca che=cache&sondage=&owntopic=&p=1&trash=&subcat= If you want me to do something about it, feel free to contact me. A graphical tutorial, like the one in http://trylinuxsd.com would be perfect too.
Re: [Cooker] urpmi features
> > And I don't think it would be a problem of legality with PLF since they > > would not be configured in advance, would they ? > The only problem is where to take the list of mirror. > > You mean it would be illegal to even put the mirrors list of PLF in the distro ? Eric
Re: [Cooker] urpmi features
Eric Fernandez wrote: Like Vox, an --info option which would give a : - the description of a package (rpm -qi) - the state : installed/uninstalled - in which source it is located The same for rpmdrake : that would be nice to merge install and remove functions, so that the search is independant of the installed/uninstalled state of a package. After searching : if it is installed, it would offer to remove it, if it is uninstalled, it would offer to to install it. A colour code would help reading (like the Suse rpm installer). Something close to the old rpmdrake ;) Eric Yes, back to 8.2 rpmdrake :-) Jiri Cerny
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Levi Ramsey wrote on Mon, Mar 17, 2003 at 12:39:17PM -0500 : > > > I'm going to working on a an automatic rebuild capability (somewhat > Gentoo-ish)... I've been thinking of doing this for a while, and the > time for action draws near... ;o) Something like a urpmb command? One that will automatically fulfil the build requires (requiring temporary root elevation)... Blue skies... Todd - -- MandrakeSoft USA http://www.mandrakesoft.com cat /boot/vmlinuz > /dev/dsp #for great justice Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+dheSlp7v05cW2woRApj5AJ9S3tv8Ze85LYSHfZYcx4KFplEbuQCgs3MV uz9cKypjbLGlx9M1w5vJArI= =Owu9 -END PGP SIGNATURE-
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Fernandez wrote on Mon, Mar 17, 2003 at 05:37:49PM - : > Good ideas Francois. Yes, all very good. > Here are mines : > * possibility to ignore one or several sources > * possibility to use only one or several media, but less restricted. There > is an actual option to use only one source, --media, but what I would like > is an option that would use only one source, but would solve and download > dependencies if any from other sources anyway. Kind of combining these two, I think it can be combined into one. At the commandline, you can only specify one source. If you specify multiple sources, it ignores all but the last one. Example: urpmi --media mainFTP --media PLF blah Will only try to fulfil dependencies from PLF. It will ignore that you told it to go to mainFTP. So by allowing multiple media to be specified on the commandline, you are implicitly disallowing the rest of the media. Though I can see the logic of specifically disallowing one source and how it can be useful if you have lots of different sources defined. Blue skies... Todd - -- MandrakeSoft USA http://www.mandrakesoft.com Easy things should be easy, and hard things should be possible. --Larry Wall Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+dhbolp7v05cW2woRArdXAJ4i5ryxiw6b/4PRHlVR53uOXw7IzgCfRNx0 8fgmX2BYnn98nUuyArxSEhg= =/ok+ -END PGP SIGNATURE-
Re: [Cooker] urpmi features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fran?ois Pons wrote on Mon, Mar 17, 2003 at 07:29:17PM +0100 : > > > * possibility to use only one or several media, but less restricted. There > > is an actual option to use only one source, --media, but what I would like ARGGH!!! So my other post was just plain wrong. I did know this. Nice. - -- | MandrakeSoft USA | Sometimes you get what you want. | | http://www.mandrakesoft.com | Sometimes you get experience.| | http://www.mandrakelinux.com |--unknown origin | Mandrake Cooker Devel Version, Kernel 2.4.21-0.13mdk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+dhcclp7v05cW2woRAgQiAKC7/utb+Xe28EgRKkarLVyNUoBeEgCgptv+ NS7WvXla6M3dDNyZ3uzAaRs= =Vsuh -END PGP SIGNATURE-
Re: [Cooker] urpmi features
François Pons wrote: * conflicts, provides and requires tag added for global rpm behaviour in order to allow broken dependencies to be not resolved or to avoid removing important package (generalize basesystem) I'm going to working on a an automatic rebuild capability (somewhat Gentoo-ish)... I've been thinking of doing this for a while, and the time for action draws near... ;o) This features is more an rpm features than a urpmi one. I think it can already be done currently by asking urpmi to get the src.rpm and calling rpm to rebuild all the downloaded packages.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 13:35, François Pons a écrit : > Any other idea are wellcome. One thing that I'd like is "round-robin source groups". Right now, and this is specially true for FTP mirrors, if urpmi tries to get a package and the FTP/WWW server is full, it will fail. When that happens, you either have to wait until there are some connections available on the FTP server (which can take hours), or install a new source (and possibly face the same problem, that server might be crowded too). Having multiple servers in a group, and doing a fallback to a random server in the list whenever a server is unavailable would make things more robust. It should also fix the problem when a Cooker mirror is slow to synchronize, if the RPM is not found, it would try another mirror that would possibly have the package. We could improve this by having a "minimum download speed" option, where if our usual mirror is really slow, it would try to find a faster one. What do you think? Jean-Michel
Re: [Cooker] urpmi features
François Pons wrote: Le lun 17/03/2003 à 18:37, Eric Fernandez a écrit : * possibility to use only one or several media, but less restricted. There is an actual option to use only one source, --media, but what I would like FYI you can use more than one source in fact, separated by comma (,). François. In fact the best improvment for urpmi would be documentation anad advertising :-)
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 19:17, Eric Fernandez a écrit : > Having urpmi.setup integrated, which would do the same than > http://plf.zarb.org/~nanardon. > > It's here : http://www.urpmi.org/en/urpmi.setup/index.html > > And I don't think it would be a problem of legality with PLF since they > would not be configured in advance, would they ? This is already the case, but using a console tools approach (not a gtk based application), look at --distrib-XXX option and all the other tunning options used. François.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 19:12, Pascal Terjan a écrit : > François Pons wrote: > > Possible features of urpmi for next release : > > > > * virtual medium (no need to update explicitely, only with synthesis ?). > > * delay before accepting using a package from a medium (cooker) > I'm not sure that's usefull. Or maybe for some important packages, but I > everyone delays testing, that will delay fixing... This can be seen as second quality testing, its purpose is to avoid using completely broken package uploaded to cooker. This has been requested by some user of cooker wich use this almost on production machine. > - Explicit priority for sources (Or at least document that currently > it's based on the order :) This has been requested for changing order on the fly, the idea is to use the same approach as --media, this can be very discriminant or global to match all local based media. > - Acces to information like package description from hdlist with urpmq This one seems to be requested too. François.
Re: [Cooker] urpmi features
Eric Fernandez wrote: Having urpmi.setup integrated, which would do the same than http://plf.zarb.org/~nanardon. It's here : http://www.urpmi.org/en/urpmi.setup/index.html It is integrated in main already. Would be nice to make a standard tool of it. And I don't think it would be a problem of legality with PLF since they would not be configured in advance, would they ? The only problem is where to take the list of mirror.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 18:39, Levi Ramsey a écrit : > > * do install of package by groups which are shorter as possible (apt-get > > like) > > Couldn't this be accomplished just as effectively through virtual > packages? This has nothing to do with virtual package in fact, this is just organization of grouping package during installation with separate transaction (in order to avoid blocking if available memory disk space is tight, or some other error appears, like conflicts with file). > > * conflicts, provides and requires tag added for global rpm behaviour in > > order to allow broken dependencies to be not resolved or to avoid > > removing important package (generalize basesystem) > > I'm going to working on a an automatic rebuild capability (somewhat > Gentoo-ish)... I've been thinking of doing this for a while, and the > time for action draws near... ;o) This features is more an rpm features than a urpmi one. François.
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 18:37, Eric Fernandez a écrit : > * possibility to use only one or several media, but less restricted. There > is an actual option to use only one source, --media, but what I would like FYI you can use more than one source in fact, separated by comma (,). François.
Re: [Cooker] urpmi features
Having urpmi.setup integrated, which would do the same than http://plf.zarb.org/~nanardon. It's here : http://www.urpmi.org/en/urpmi.setup/index.html And I don't think it would be a problem of legality with PLF since they would not be configured in advance, would they ? Eric
Re: [Cooker] urpmi features
François Pons wrote: Possible features of urpmi for next release : * virtual medium (no need to update explicitely, only with synthesis ?). * delay before accepting using a package from a medium (cooker) I'm not sure that's usefull. Or maybe for some important packages, but I everyone delays testing, that will delay fixing... * always ask confirmation if fuzzy search is used (even for 1 package) [+] * on the fly sorting of media (according to regex like file,rsync,ftp,http) * urpm centralized tools, as well as perl-URPM managing media. [+] new format of urpmi.cfg is already a good thing but seeing how easy it is tu handle sources information with perl-URPM, that should be complicated to have tools :-) * p2p urpmi database (export database as magic synthesis) Would be fun :-) * -h by default for urpmi.addmedia [+] * do install of package by groups which are shorter as possible (apt-get like) Would be nice. Good luck for an optimized algorithm :) * allow file conflicts error to be handled by recovering errors and try again. Would be very nice * conflicts, provides and requires tag added for global rpm behaviour in order to allow broken dependencies to be not resolved or to avoid removing important package (generalize basesystem) Any other idea are wellcome. - Explicit priority for sources (Or at least document that currently it's based on the order :) - Acces to information like package description from hdlist with urpmq
Re: [Cooker] urpmi features
Like Vox, an --info option which would give a : - the description of a package (rpm -qi) - the state : installed/uninstalled - in which source it is located The same for rpmdrake : that would be nice to merge install and remove functions, so that the search is independant of the installed/uninstalled state of a package. After searching : if it is installed, it would offer to remove it, if it is uninstalled, it would offer to to install it. A colour code would help reading (like the Suse rpm installer). Something close to the old rpmdrake ;) Eric
Re: [Cooker] urpmi features
Le lun 17/03/2003 à 13:37, Eric Fernandez a écrit : > Good ideas Francois. > Here are mines : > * possibility to ignore one or several sources I totally support this one. Having a --excludemedia option would be nice when you want, for example, to upgrade to the latest cooker, but don't want to upgrade to the latest contribs. (Like with apache/apache2, gd/gd2, horde/horde2). > * possibility to use only one or several media, but less restricted. There > is an actual option to use only one source, --media, but what I would like > is an option that would use only one source, but would solve and download > dependencies if any from other sources anyway. Jean-Michel
Re: [Cooker] urpmi features
This time François Pons <[EMAIL PROTECTED]> becomes daring and writes: > Possible features of urpmi for next release : > > * virtual medium (no need to update explicitely, only with synthesis ?). > * delay before accepting using a package from a medium (cooker) > * always ask confirmation if fuzzy search is used (even for 1 package) > * on the fly sorting of media (according to regex like > file,rsync,ftp,http) > * urpm centralized tools, as well as perl-URPM managing media. > * p2p urpmi database (export database as magic synthesis) > * -h by default for urpmi.addmedia > * do install of package by groups which are shorter as possible (apt-get > like) > * allow file conflicts error to be handled by recovering errors and try > again. > * conflicts, provides and requires tag added for global rpm behaviour in > order to allow broken dependencies to be not resolved or to avoid > removing important package (generalize basesystem) > > Any other idea are wellcome. An --info or whatever switch to get the description of an uninstalled package, just as you get it with rpm --info packagename when it's already installed. And the build-from-source thing that Levi mentioned...specially useful if urpmi "remembers" what has been built from source and what has been installed from binaries, and updates accordingly...that would absolutely rule :) Vox -- Think of the Linux community as a niche economy isolated by its beliefs. Kind of like the Amish, except that our religion requires us to use _higher_ technology than everyone else. -- Donald B. Marti Jr. pgp0.pgp Description: PGP signature
Re: [Cooker] urpmi features
On Mon Mar 17 18:35 +0100, François Pons wrote: > Possible features of urpmi for next release : > > * virtual medium (no need to update explicitely, only with synthesis ?). > * delay before accepting using a package from a medium (cooker) > * always ask confirmation if fuzzy search is used (even for 1 package) > * on the fly sorting of media (according to regex like > file,rsync,ftp,http) > * urpm centralized tools, as well as perl-URPM managing media. > * p2p urpmi database (export database as magic synthesis) > * -h by default for urpmi.addmedia > * do install of package by groups which are shorter as possible (apt-get > like) Couldn't this be accomplished just as effectively through virtual packages? > * allow file conflicts error to be handled by recovering errors and try > again. > * conflicts, provides and requires tag added for global rpm behaviour in > order to allow broken dependencies to be not resolved or to avoid > removing important package (generalize basesystem) I'm going to working on a an automatic rebuild capability (somewhat Gentoo-ish)... I've been thinking of doing this for a while, and the time for action draws near... ;o) -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] The food of love is Mandrake root. GPG Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: The Pass.ogg Linux 2.4.21-0.13mdk 12:30:01 up 2 days, 15:33, 11 users, load average: 0.02, 0.01, 0.00
Re: [Cooker] urpmi features
Good ideas Francois. Here are mines : * possibility to ignore one or several sources * possibility to use only one or several media, but less restricted. There is an actual option to use only one source, --media, but what I would like is an option that would use only one source, but would solve and download dependencies if any from other sources anyway. Eric
Re: [Cooker] urpmi features
François Pons wrote: Possible features of urpmi for next release : ... Any other idea are wellcome. François. Priority for sources. So that if two (or more) totaly same packages exist in two (or more) sources you can set the priority so that the package gets installed from the media with higher priority. For example some prefere local sorces to have higher priority and some prefer some FTP server for packages. -- Live long and prosper!
