From chess at chessgriffin.com Tue Apr 7 14:14:15 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Tue, 7 Apr 2009 10:14:15 -0400 Subject: [sbopkg-users] Sbopkg 0.27.1 Released Message-ID: <20090407141414.GA21806@localhost> A new sbopkg version 0.27.1 has been released. This is a bugfix release to the 0.27.x -stable branch of sbopkg and is a recommended upgrade for all sbopkg users. There are no major changes or new features and therefore no changes to sbopkg.conf are needed. Here is the complete ChangeLog.txt for this release: * Remove some useless code from check_for_latest and also fix the download folder for sbopkg updates. Thanks to David Somero for the bug report. * Re-implement the code that checks for renamed software; fix upgrading of renamed packages; thanks to Phillip Warner for raising the issues with the older code; add wbxml2->libwbxml to sbopkg-renames; thanks to Mauro Giachero for working on these fixes. * Fix a tr invocation issue where in certain instances, sbopkg would not run from certain directories; thanks to Marie-Claude Collilieux for the bug report. * Alter sed expression in download code to work around calcurse filename idiosyncrasy; thanks to Glenn Becker for the bug report. * Move French man pages into correct /usr/man/fr* location and remove them from the /docs directory; update French man pages; thanks to Marie-Claude Collilieux. * Fix a problem with the Pre-Check Log dialog being non-scrollable and having a visual glitch. Thanks to Erik Hanson for the bug report. * Remove a problem where the "Using the queuefile QUEUEFILE" messages could be incorrect. * Fix a possible infinite loop when building in CLI mode. * Fix an issue with an ncurses check and the cleanup() function. The full ChangeLog.txt can be read here: http://www.sbopkg.org/files/ChangeLog.txt We are still hard at work on doing a major cleanup and code audit of sbopkg. This work is focused on the current -trunk branch of sbopkg, so anyone who happens to be running sbopkg from SVN please be aware that breakage is expected while this cleanup continues. In the meantime, however, we are going to continue to maintain this 0.27.x stable branch and will release additional bugfixes as they become necessary. A noarch package and source tarball for sbopkg version 0.27.1 can be found at the sbopkg project website: http://www.sbopkg.org On behalf of the sbopkg team, enjoy! -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From me at alkos333.net Wed Apr 15 20:54:25 2009 From: me at alkos333.net (alkos333) Date: Wed, 15 Apr 2009 15:54:25 -0500 Subject: [sbopkg-users] Feature proposal Message-ID: I have a queue named "all" which contains all of my currently installed packages in appropriate order (as far as dependencies are concerned). It took me quite a while to construct the the queue and then do several runs to sort out dependencies. What about creating a feature that would first queue all of the currently installed packages into the queue. Second, it would scan their README files and look for name hits and move the packages with those names before the package whose README is being scanned. Basically, I'm in no way trying to automate the dependency check because there were still be conflicts, but at the very least, this will get the overall queue as close to the functioning state as possible and the admin can then finish the rest. This was just an idea that hit me as I was creating a back-up queue for recompiling all of the SBo package after an update let's say. -- Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." - http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html From mauro.giachero at gmail.com Thu Apr 16 09:10:04 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Thu, 16 Apr 2009 11:10:04 +0200 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: Message-ID: On Wed, Apr 15, 2009 at 10:54 PM, alkos333 wrote: > I have a queue named "all" which contains all of my currently > installed packages in appropriate order (as far as dependencies are > concerned). It took me quite a while to construct the the queue and > then do several runs to sort out dependencies. > > What about creating a feature that would first queue all of the > currently installed packages into the queue. Second, it would scan > their README files and look for name hits and move the packages with > those names before the package whose README is being scanned. > Basically, I'm in no way trying to automate the dependency check > because there were still be conflicts, but at the very least, this > will get the overall queue as close to the functioning state as > possible and the admin can then finish the rest. > > This was just an idea that hit me as I was creating a back-up queue > for recompiling all of the SBo package after an update let's say. Unfortunately, this is not as simple as it looks. It's very easy to have circular "dependencies" ("X needs Y" / "[Y] is a dependency of X"), as well as broken dependencies ("You cannot install X and Y together"). Anyway, why a single queue? I think storing one queue per (relevant) package would be far more flexible, given that sbopkg makes loading and merging multiple queue files really easy. And of course, somebody could also build up a queue archive. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at alkos333.net Thu Apr 16 10:52:43 2009 From: me at alkos333.net (alkos333) Date: Thu, 16 Apr 2009 05:52:43 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: Message-ID: On Thu, Apr 16, 2009 at 4:10 AM, Mauro Giachero wrote: > On Wed, Apr 15, 2009 at 10:54 PM, alkos333 wrote: >> >> I have a queue named "all" which contains all of my currently >> installed packages in appropriate order (as far as dependencies are >> concerned). ?It took me quite a while to construct the the queue and >> then do several runs to sort out dependencies. >> >> What about creating a feature that would first queue all of the >> currently installed packages into the queue. ?Second, it would scan >> their README files and look for name hits and move the packages with >> those names before the package whose README is being scanned. >> Basically, I'm in no way trying to automate the dependency check >> because there were still be conflicts, but at the very least, this >> will get the overall queue as close to the functioning state as >> possible and the admin can then finish the rest. >> >> This was just an idea that hit me as I was creating a back-up queue >> for recompiling all of the SBo package after an update let's say. > > Unfortunately, this is not as simple as it looks. It's very easy to have > circular "dependencies" ("X needs Y" / "[Y] is a dependency of X"), as well > as broken dependencies ("You cannot install X and Y together"). > > Anyway, why a single queue? I think storing one queue per (relevant) package > would be far more flexible, given that sbopkg makes loading and merging > multiple queue files really easy. And of course, somebody could also build > up a queue archive. > > -- > Mauro Giachero > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > I know it' snot as easy as it looks, but it's doable. One file because I don't have to worry about merging them and running several files. I can just load one and tell it to run through the entire thing. Works like a charm here :) -- Samuel Goldwyn - "A wide screen just makes a bad film twice as bad." - http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html From chess at chessgriffin.com Thu Apr 16 18:00:27 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 16 Apr 2009 14:00:27 -0400 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: Message-ID: <20090416180027.GA13722@localhost> * alkos333 [2009-04-16 05:52:43]: > I know it' snot as easy as it looks, but it's doable. One file > because I don't have to worry about merging them and running several > files. I can just load one and tell it to run through the entire > thing. Works like a charm here :) > Perhaps a compromise would be to just have the ability to add all installed SBo packages to the queue? This would at least give the user something to start with. Once they are in the queue, then the user can manually edit the queue and move things up and down the list. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Thu Apr 16 18:16:25 2009 From: rw at rlworkman.net (Robby Workman) Date: Thu, 16 Apr 2009 13:16:25 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: Message-ID: <20090416131625.6cb7e172@liberty.rlwhome.lan> On Thu, 16 Apr 2009 05:52:43 -0500 alkos333 wrote: > On Thu, Apr 16, 2009 at 4:10 AM, Mauro Giachero wrote: > > Anyway, why a single queue? I think storing one queue per > > (relevant) package would be far more flexible, given that sbopkg > > makes loading and merging multiple queue files really easy. And of > > course, somebody could also build up a queue archive. > > I know it' snot as easy as it looks, but it's doable. One file > because I don't have to worry about merging them and running several > files. I can just load one and tell it to run through the entire > thing. Works like a charm here :) > Maybe I'm not fully understanding the goal here, but what if sbopkg were able to treat a queue as a package? IOW, you would be able to do something like this: queue_all=queue1,queue2,queue3,... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From me at alkos333.net Thu Apr 16 19:35:35 2009 From: me at alkos333.net (alkos333) Date: Thu, 16 Apr 2009 14:35:35 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: <20090416180027.GA13722@localhost> References: <20090416180027.GA13722@localhost> Message-ID: On Thu, Apr 16, 2009 at 1:00 PM, Chess Griffin wrote: > * alkos333 [2009-04-16 05:52:43]: > >> I know it' snot as easy as it looks, but it's doable. ?One file >> because I don't have to worry about merging them and running several >> files. ?I can just load one and tell it to run through the entire >> thing. ?Works like a charm here :) >> > > Perhaps a compromise would be to just have the ability to add all > installed SBo packages to the queue? ?This would at least give the user > something to start with. ?Once they are in the queue, then the user can > manually edit the queue and move things up and down the list. > > -- > Chess Griffin > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > That would certainly be nice. What if I provide a successful, implementation of my idea, would you take a closer look at it? You guys mind if it's in python or would you rather have everything written in bash? From jsunx1 at bellsouth.net Thu Apr 16 21:47:59 2009 From: jsunx1 at bellsouth.net (slakmagik) Date: Thu, 16 Apr 2009 17:47:59 -0400 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416180027.GA13722@localhost> Message-ID: <20090416214759.GB11644@surfandslam> On 2009-04-16 (Thu) 14:35:35 [-0500], alkos333 wrote: > On Thu, Apr 16, 2009 at 1:00 PM, Chess Griffin wrote: > > * alkos333 [2009-04-16 05:52:43]: > > > That would certainly be nice. What if I provide a successful, > implementation of my idea, would you take a closer look at it? > Although I've liked several of your suggestions before and appreciate them all, I'm personally against this idea in principle, aside from implementation. IMO, sbopkg provides the principle of the queue, the ability to edit your queues, and the ability to handle lists of queues. Anything else along these lines really is dependency handling (even if "soft") and is up to the user. In this regard, sbopkg is just another tool and you can lash it together with other tools to make the special-purpose tool you want or write a separate tool alongside it. But it, itself, shouldn't go this far into parsing unstructured text for dependency information in order to (non-robustly and, by design, sometimes incompletely) auto-order queues. But that's just me. > You guys mind if it's in python or would you rather have everything > written in bash? I'd very much rather have everything in bash. If this is in python the next guy should be able to add stuff in ruby and the next in foo and the next in bar and that makes for an auditing and maintenance nightmare. Also, while we assume a standard Slackware install and figure you have the basic shell, coreutils, dialog and a few other things (and this would include python), I don't want people to be forced to dispense with sbopkg (or parts of it) if they want to uninstall stuff like python or ruby or whatever. Again, just my opinion. From me at alkos333.net Thu Apr 16 22:32:24 2009 From: me at alkos333.net (alkos333) Date: Thu, 16 Apr 2009 17:32:24 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: <20090416214759.GB11644@surfandslam> References: <20090416180027.GA13722@localhost> <20090416214759.GB11644@surfandslam> Message-ID: On Thu, Apr 16, 2009 at 4:47 PM, slakmagik wrote: > On 2009-04-16 (Thu) 14:35:35 [-0500], alkos333 wrote: >> On Thu, Apr 16, 2009 at 1:00 PM, Chess Griffin wrote: >> > * alkos333 [2009-04-16 05:52:43]: >> > >> That would certainly be nice. ?What if I provide a successful, >> implementation of my idea, would you take a closer look at it? >> > > Although I've liked several of your suggestions before and appreciate > them all, I'm personally against this idea in principle, aside from > implementation. IMO, sbopkg provides the principle of the queue, the > ability to edit your queues, and the ability to handle lists of queues. > Anything else along these lines really is dependency handling (even if > "soft") and is up to the user. In this regard, sbopkg is just another > tool and you can lash it together with other tools to make the > special-purpose tool you want or write a separate tool alongside it. But > it, itself, shouldn't go this far into parsing unstructured text for > dependency information in order to (non-robustly and, by design, > sometimes incompletely) auto-order queues. But that's just me. > >> You guys mind if it's in python or would you rather have everything >> written in bash? > > I'd very much rather have everything in bash. If this is in python the > next guy should be able to add stuff in ruby and the next in foo and the > next in bar and that makes for an auditing and maintenance nightmare. > Also, while we assume a standard Slackware install and figure you have > the basic shell, coreutils, dialog and a few other things (and this > would include python), I don't want people to be forced to dispense with > sbopkg (or parts of it) if they want to uninstall stuff like python or > ruby or whatever. Again, just my opinion. > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > Point well taken. -- Samuel Goldwyn - "A wide screen just makes a bad film twice as bad." - http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html From mauro.giachero at gmail.com Fri Apr 17 21:08:53 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Fri, 17 Apr 2009 23:08:53 +0200 Subject: [sbopkg-users] Feature proposal In-Reply-To: <20090416131625.6cb7e172@liberty.rlwhome.lan> References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: On Thu, Apr 16, 2009 at 8:16 PM, Robby Workman wrote: > On Thu, 16 Apr 2009 05:52:43 -0500 alkos333 wrote: > > > On Thu, Apr 16, 2009 at 4:10 AM, Mauro Giachero wrote: > > > Anyway, why a single queue? I think storing one queue per > > > (relevant) package would be far more flexible, given that sbopkg > > > makes loading and merging multiple queue files really easy. And of > > > course, somebody could also build up a queue archive. > > > > I know it' snot as easy as it looks, but it's doable. One file > > because I don't have to worry about merging them and running several > > files. I can just load one and tell it to run through the entire > > thing. Works like a charm here :) > > Maybe I'm not fully understanding the goal here, but what if sbopkg > were able to treat a queue as a package? IOW, you would be able to do > something like this: > > queue_all=queue1,queue2,queue3,... Being able to do this kind of thing has puzzled me for some time (despite me being probably the only sbopkg user not using saved queues). The problematic side here is being able to actually manage (e.g. create) such queue. sbopkg code assumes that a queue is a flat list of packages, and changing it to manage a nested structure is far from easy :-/. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at alkos333.net Fri Apr 17 21:20:40 2009 From: me at alkos333.net (alkos333) Date: Fri, 17 Apr 2009 16:20:40 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: On Fri, Apr 17, 2009 at 4:08 PM, Mauro Giachero wrote: > On Thu, Apr 16, 2009 at 8:16 PM, Robby Workman wrote: >> >> On Thu, 16 Apr 2009 05:52:43 -0500 alkos333 wrote: >> >> > On Thu, Apr 16, 2009 at 4:10 AM, Mauro Giachero wrote: >> > > Anyway, why a single queue? I think storing one queue per >> > > (relevant) package would be far more flexible, given that sbopkg >> > > makes loading and merging multiple queue files really easy. And of >> > > course, somebody could also build up a queue archive. >> > >> > I know it' snot as easy as it looks, but it's doable. ?One file >> > because I don't have to worry about merging them and running several >> > files. ?I can just load one and tell it to run through the entire >> > thing. ?Works like a charm here :) >> >> Maybe I'm not fully understanding the goal here, but what if sbopkg >> were able to treat a queue as a package? ?IOW, you would be able to do >> something like this: >> >> queue_all=queue1,queue2,queue3,... > > Being able to do this kind of thing has puzzled me for some time (despite me > being probably the only sbopkg user not using saved queues). > The problematic side here is being able to actually manage (e.g. create) > such queue. sbopkg code assumes that a queue is a flat list of packages, and > changing it to manage a nested structure is far from easy :-/. > > -- > Mauro Giachero > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > Why don't you use queues? How many packages do you have installed? -- George Carlin - "Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stu... - http://www.brainyquote.com/quotes/authors/g/george_carlin.html From mauro.giachero at gmail.com Fri Apr 17 21:41:52 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Fri, 17 Apr 2009 23:41:52 +0200 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: On Fri, Apr 17, 2009 at 11:20 PM, alkos333 wrote: > On Fri, Apr 17, 2009 at 4:08 PM, Mauro Giachero > wrote: > > > ([I'm] probably the only sbopkg user not using saved queues). > > Why don't you use queues? How many packages do you have installed? > 76 on the computer I'm typing this. And for the reason... I have QUEUEDIR set to /tmp/SBo/queues, /tmp is tmpfs and I'm really lazy sometimes :-) I should really start to use them. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at alkos333.net Fri Apr 17 22:01:27 2009 From: me at alkos333.net (alkos333) Date: Fri, 17 Apr 2009 17:01:27 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: On Fri, Apr 17, 2009 at 4:41 PM, Mauro Giachero wrote: > On Fri, Apr 17, 2009 at 11:20 PM, alkos333 wrote: >> >> On Fri, Apr 17, 2009 at 4:08 PM, Mauro Giachero >> wrote: >> >> > ([I'm] probably the only sbopkg user not using saved queues). >> >> Why don't you use queues? ?How many packages do you have installed? > > 76 on the computer I'm typing this. > And for the reason... I have QUEUEDIR set to /tmp/SBo/queues, /tmp is tmpfs > and I'm really lazy sometimes :-) > I should really start to use them. > > -- > Mauro Giachero > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > Yes, lazy I can totally understand :). Isn't Robby talking about merging several text files really? From mauro.giachero at gmail.com Fri Apr 17 22:10:01 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Sat, 18 Apr 2009 00:10:01 +0200 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: On Sat, Apr 18, 2009 at 12:01 AM, alkos333 wrote: > > Isn't Robby talking about merging several text files really? > I read Robby's proposal as a "let's support queues referring to other queues instead of packages". This someway involves having a text file containing queue names, hence the management problems. If the idea is simply to be able to merge several queues (i.e. create per-package queues, and use them to create a single queue containing their union), then this is already possible: just load all the queues in sbopkg and save the result. Or you had something different in mind? -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From rw at rlworkman.net Fri Apr 17 22:44:31 2009 From: rw at rlworkman.net (Robby Workman) Date: Fri, 17 Apr 2009 17:44:31 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> Message-ID: <20090417174431.68da9520@liberty.rlwhome.lan> On Sat, 18 Apr 2009 00:10:01 +0200 Mauro Giachero wrote: > On Sat, Apr 18, 2009 at 12:01 AM, alkos333 wrote: > > > > > Isn't Robby talking about merging several text files really? > > > > I read Robby's proposal as a "let's support queues referring to other > queues instead of packages". This someway involves having a text file > containing queue names, hence the management problems. > > If the idea is simply to be able to merge several queues (i.e. create > per-package queues, and use them to create a single queue containing > their union), then this is already possible: just load all the queues > in sbopkg and save the result. > > Or you had something different in mind? Well, I haven't written *any* code for sbopkg, and I don't expect to have time to do so in the future, so I should probably be ignored. That being said... You've got the gist of my idea, Mauro. It would involve abstracting the concept of a queue, in such a way that a "multimedia" queue might contain the following: mplayer x264 ffmpeg blahblah {and all their deps} A "network" queue might contain these: xtables-addons pidgin-otr libotr blahblahblah and deps A "games" queue might look like this: monkey-bubble frozenbubble tuxracer supertux blahblah and deps Long story short, you could then have a set of custom queuefiles that might look something like this: kidsbox: multimedia graphics games devbox: network devel libs virtualization all: multimedia graphics games network devel libs virtualization I harbor no illusions that implementing such a thing would be either simple or necessarily desirable. Unlike some, I *do* realize that some features would cause a project to stray from its primary goals if they were implemented... :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From me at alkos333.net Sat Apr 18 00:41:31 2009 From: me at alkos333.net (alkos333) Date: Fri, 17 Apr 2009 19:41:31 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: <20090417174431.68da9520@liberty.rlwhome.lan> References: <20090416131625.6cb7e172@liberty.rlwhome.lan> <20090417174431.68da9520@liberty.rlwhome.lan> Message-ID: On Fri, Apr 17, 2009 at 5:44 PM, Robby Workman wrote: > On Sat, 18 Apr 2009 00:10:01 +0200 > Mauro Giachero wrote: > >> On Sat, Apr 18, 2009 at 12:01 AM, alkos333 wrote: >> >> > >> > Isn't Robby talking about merging several text files really? >> > >> >> I read Robby's proposal as a "let's support queues referring to other >> queues instead of packages". This someway involves having a text file >> containing queue names, hence the management problems. >> >> If the idea is simply to be able to merge several queues (i.e. create >> per-package queues, and use them to create a single queue containing >> their union), then this is already possible: just load all the queues >> in sbopkg and save the result. >> >> Or you had something different in mind? > > > Well, I haven't written *any* code for sbopkg, and I don't expect to > have time to do so in the future, so I should probably be ignored. > That being said... > > You've got the gist of my idea, Mauro. ?It would involve abstracting > the concept of a queue, in such a way that a "multimedia" queue might > contain the following: > ?mplayer x264 ffmpeg blahblah {and all their deps} > A "network" queue might contain these: > ?xtables-addons pidgin-otr libotr blahblahblah and deps > A "games" queue might look like this: > ?monkey-bubble frozenbubble tuxracer supertux blahblah and deps > > Long story short, you could then have a set of custom queuefiles that > might look something like this: > ?kidsbox: multimedia graphics games > ?devbox: network devel libs virtualization > ?all: multimedia graphics games network devel libs virtualization > > I harbor no illusions that implementing such a thing would be either > simple or necessarily desirable. ?Unlike some, I *do* realize that some > features would cause a project to stray from its primary goals if they > were implemented... ?:-) > > -RW > > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > Ok, Robby.... no fighting :P From chess at chessgriffin.com Sat Apr 18 02:24:27 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Fri, 17 Apr 2009 22:24:27 -0400 Subject: [sbopkg-users] Feature proposal' In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> <20090417174431.68da9520@liberty.rlwhome.lan> Message-ID: <20090418022427.GB13872@localhost> * alkos333 [2009-04-17 19:41:31]: > On Fri, Apr 17, 2009 at 5:44 PM, Robby Workman wrote: > > On Sat, 18 Apr 2009 00:10:01 +0200 > > Mauro Giachero wrote: > > > >> On Sat, Apr 18, 2009 at 12:01 AM, alkos333 wrote: > >> > >> > > >> > Isn't Robby talking about merging several text files really? > >> > > >> > >> I read Robby's proposal as a "let's support queues referring to other > >> queues instead of packages". This someway involves having a text file > >> containing queue names, hence the management problems. > >> > >> If the idea is simply to be able to merge several queues (i.e. create > >> per-package queues, and use them to create a single queue containing > >> their union), then this is already possible: just load all the queues > >> in sbopkg and save the result. > >> > >> Or you had something different in mind? > > > > > > Well, I haven't written *any* code for sbopkg, and I don't expect to > > have time to do so in the future, so I should probably be ignored. > > That being said... > > > > You've got the gist of my idea, Mauro. ?It would involve abstracting > > the concept of a queue, in such a way that a "multimedia" queue might > > contain the following: > > ?mplayer x264 ffmpeg blahblah {and all their deps} > > A "network" queue might contain these: > > ?xtables-addons pidgin-otr libotr blahblahblah and deps > > A "games" queue might look like this: > > ?monkey-bubble frozenbubble tuxracer supertux blahblah and deps > > > > Long story short, you could then have a set of custom queuefiles that > > might look something like this: > > ?kidsbox: multimedia graphics games > > ?devbox: network devel libs virtualization > > ?all: multimedia graphics games network devel libs virtualization > > > > I harbor no illusions that implementing such a thing would be either > > simple or necessarily desirable. ?Unlike some, I *do* realize that some > > features would cause a project to stray from its primary goals if they > > were implemented... ?:-) > > > > -RW > > > > > > _______________________________________________ > > sbopkg-users mailing list > > sbopkg-users at sbopkg.org > > http://sbopkg.org/mailman/listinfo/sbopkg-users > > > > > > Ok, Robby.... no fighting :P Hey everyone -- just been traveling for work and have not had a chance to get caught up until now, and I only have a moment. Overall, I see what Robby is saying and it does seem interesting. That feature along with the 'add all SBo packages to the queue' might go a long way towards what alkos333 is looking for, perhaps. I could see that it would be helpful to essentially be able to string several separate queues together. I also agree with slackmagik that any contributions should be in bash. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Sat Apr 18 02:32:37 2009 From: rw at rlworkman.net (Robby Workman) Date: Fri, 17 Apr 2009 21:32:37 -0500 Subject: [sbopkg-users] Feature proposal In-Reply-To: References: <20090416131625.6cb7e172@liberty.rlwhome.lan> <20090417174431.68da9520@liberty.rlwhome.lan> Message-ID: <20090417213237.2a68c0af@liberty.rlwhome.lan> On Fri, 17 Apr 2009 19:41:31 -0500 alkos333 wrote: > On Fri, Apr 17, 2009 at 5:44 PM, Robby Workman wrote: > > I harbor no illusions that implementing such a thing would be either > > simple or necessarily desirable. ?Unlike some, I *do* realize that > > some features would cause a project to stray from its primary goals > > if they were implemented... ?:-) > > > > Ok, Robby.... no fighting :P In case it wasn't clear, that wasn't aimed at you. It was actually just a general statement along the lines of "we get that a lot in Slackware development," for the most part. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chess at chessgriffin.com Sun Apr 19 02:41:49 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Sat, 18 Apr 2009 22:41:49 -0400 Subject: [sbopkg-users] Feature proposal In-Reply-To: <20090417213237.2a68c0af@liberty.rlwhome.lan> References: <20090416131625.6cb7e172@liberty.rlwhome.lan> <20090417174431.68da9520@liberty.rlwhome.lan> <20090417213237.2a68c0af@liberty.rlwhome.lan> Message-ID: <20090419024149.GC14009@localhost> * Robby Workman [2009-04-17 21:32:37]: > On Fri, 17 Apr 2009 19:41:31 -0500 > alkos333 wrote: > > > On Fri, Apr 17, 2009 at 5:44 PM, Robby Workman wrote: > > > I harbor no illusions that implementing such a thing would be either > > > simple or necessarily desirable. ?Unlike some, I *do* realize that > > > some features would cause a project to stray from its primary goals > > > if they were implemented... ?:-) > > > > > > > Ok, Robby.... no fighting :P > > > In case it wasn't clear, that wasn't aimed at you. It was actually > just a general statement along the lines of "we get that a lot in > Slackware development," for the most part. > > -RW Heh, no doubt. :-) -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From chess at chessgriffin.com Thu Apr 30 15:44:31 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 30 Apr 2009 11:44:31 -0400 Subject: [sbopkg-users] Sbopkg 0.27.2 Released Message-ID: <20090430154431.GA25657@localhost> A new sbopkg version 0.27.2 has been released. This is a second bugfix release to the 0.27.x -stable branch of sbopkg. While there are no major changes or new features, this release fixes some important bugs, so it is a recommended upgrade for all users. Here is the ChangeLog for this release: * Remove a stale 'find' call, which slightly improves the update feature. * Add acroread->adobe-reader and GNOME-Colors->gnome-colors to sbopkg-renames.new. * Display a message when no packages are installed instead of doing nothing. * Properly quote the current working directory variable in the event there are spaces in the directory name. * Fix a bug where 'sbopkg -c -v local' would display a dialog even though running in cli mode. * Fix issue where the 'games' directory was non-browsable due to a slack-desc file containing double-quotes in the first line; thanks to Glenn Becker for the original bug report. Be sure to migrate the changes from sbopkg-renames.new to your sbopkg-renames (or just rename the file) in order to pick up the two more renamed packages. In subversionland, major commits were recently made to the -trunk branch of sbopkg that included a gigantic cleanup patch that was the result of several weeks of hard work by the whole sbopkg team. We believe this cleanup, which affected just about every part of sbopkg, should make the codebase more readable, more manageable, and less bug-prone. We plan to continue to work hard on the -trunk branch until it's ready for release. In the meantime, as previously mentioned, we will continue to put out these bugfix releases to the 0.27.x branch as they are needed. A noarch package and source tarball for sbopkg 0.27.2 can be found at the sbopkg project website: http://www.sbopkg.org. Enjoy! -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Thu Apr 30 17:32:27 2009 From: rw at rlworkman.net (Robby Workman) Date: Thu, 30 Apr 2009 12:32:27 -0500 Subject: [sbopkg-users] Sbopkg 0.27.2 Released In-Reply-To: <20090430154431.GA25657@localhost> References: <20090430154431.GA25657@localhost> Message-ID: <20090430123227.7cde87d3@liberty.rlwhome.lan> On Thu, 30 Apr 2009 11:44:31 -0400 Chess Griffin wrote: > Be sure to migrate the changes from sbopkg-renames.new to your > sbopkg-renames (or just rename the file) in order to pick up the two > more renamed packages. What's the rationale for a this being an admin-editable file? To clarify, what's the potential use case for it being necessary? If it is necessary for the local admin to have a 'renames' file or some such, then I'd suggest having sbopkg look for an "sbopkg-renames.local" file for that -- I don't think it's a good idea to potentially allow the renames file to be out of sync (which the .new allows). -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chess at chessgriffin.com Thu Apr 30 18:03:13 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 30 Apr 2009 14:03:13 -0400 Subject: [sbopkg-users] Sbopkg 0.27.2 Released In-Reply-To: <20090430123227.7cde87d3@liberty.rlwhome.lan> References: <20090430154431.GA25657@localhost> <20090430123227.7cde87d3@liberty.rlwhome.lan> Message-ID: <20090430180312.GA25687@localhost> * Robby Workman [2009-04-30 12:32:27]: > On Thu, 30 Apr 2009 11:44:31 -0400 > Chess Griffin wrote: > > > Be sure to migrate the changes from sbopkg-renames.new to your > > sbopkg-renames (or just rename the file) in order to pick up the two > > more renamed packages. > > > What's the rationale for a this being an admin-editable file? To > clarify, what's the potential use case for it being necessary? The original idea was to have an easy way to take care of renamed files without necessarily having to update sbopkg itself. If there is a lag between a renamed file and an sbopkg release, the admin can edit the file himself. Additionally, there is the potential that someone might want to make use of the 'local' repo feature in sbopkg, and have a 'local' version of an app that, through the renames file, can override something in the official SBo repo, e.g. in sbopkg-renames: mplayer=my_custom_mplayer_with_leet_config_options In this case, if the admin 'updates' his local leet mplayer script, then it will appear as an update in sbopkg. > > If it is necessary for the local admin to have a 'renames' file or some > such, then I'd suggest having sbopkg look for an "sbopkg-renames.local" > file for that -- I don't think it's a good idea to potentially allow > the renames file to be out of sync (which the .new allows). > Still, I can understand the overall concern that the renames file could be out of sync. Maybe, as you suggest, having both an sbopkg-renames and an sbopkg-renames.local where the admin can add personalized changes is the way to go here. The sbopkg-renames is overwritten each time sbopkg is updated, thus ensuring the new additions are picked up without wiping out anything in sbopkg-renames.local. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From chess at chessgriffin.com Thu Apr 30 18:11:20 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 30 Apr 2009 14:11:20 -0400 Subject: [sbopkg-users] Sbopkg 0.27.2 Released In-Reply-To: <20090430180312.GA25687@localhost> References: <20090430154431.GA25657@localhost> <20090430123227.7cde87d3@liberty.rlwhome.lan> <20090430180312.GA25687@localhost> Message-ID: <20090430181120.GA25754@localhost> * Chess Griffin [2009-04-30 14:03:12]: > In this case, if the admin 'updates' his local leet mplayer script, then > it will appear as an update in sbopkg. > Clarification: this hasn't been implemented yet but is something I have been hacking on ... I got my -devel work mixed up with -release. :-) Still, I like the separate file for the other reasons noted, and I think the .local is a good way to address the concern you raised. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Thu Apr 30 18:18:16 2009 From: rw at rlworkman.net (Robby Workman) Date: Thu, 30 Apr 2009 13:18:16 -0500 Subject: [sbopkg-users] Sbopkg 0.27.2 Released In-Reply-To: <20090430180312.GA25687@localhost> References: <20090430154431.GA25657@localhost> <20090430123227.7cde87d3@liberty.rlwhome.lan> <20090430180312.GA25687@localhost> Message-ID: <20090430131816.4c767cff@liberty.rlwhome.lan> On Thu, 30 Apr 2009 14:03:13 -0400 Chess Griffin wrote: > * Robby Workman [2009-04-30 12:32:27]: > > > On Thu, 30 Apr 2009 11:44:31 -0400 > > Chess Griffin wrote: > > > > > Be sure to migrate the changes from sbopkg-renames.new to your > > > sbopkg-renames (or just rename the file) in order to pick up the > > > two more renamed packages. > > > > > > What's the rationale for a this being an admin-editable file? To > > clarify, what's the potential use case for it being necessary? > > The original idea was to have an easy way to take care of renamed > files without necessarily having to update sbopkg itself. If there > is a lag between a renamed file and an sbopkg release, the admin can > edit the file himself. Okay, that's fair. Keep reading though... :-) > Additionally, there is the potential that someone might want to make > use of the 'local' repo feature in sbopkg, and have a 'local' version > of an app that, through the renames file, can override something in > the official SBo repo, e.g. in sbopkg-renames: > > mplayer=my_custom_mplayer_with_leet_config_options > > In this case, if the admin 'updates' his local leet mplayer script, > then it will appear as an update in sbopkg. Right; keep reading... :-) > > If it is necessary for the local admin to have a 'renames' file or > > some such, then I'd suggest having sbopkg look for an > > "sbopkg-renames.local" file for that -- I don't think it's a good > > idea to potentially allow the renames file to be out of sync (which > > the .new allows). > > > > Still, I can understand the overall concern that the renames file > could be out of sync. Maybe, as you suggest, having both an > sbopkg-renames and an sbopkg-renames.local where the admin can add > personalized changes is the way to go here. The sbopkg-renames is > overwritten each time sbopkg is updated, thus ensuring the new > additions are picked up without wiping out anything in > sbopkg-renames.local. That the admin might want to get a "head start" on a renamed package before sbopkg has an updated version is a non-issue; he could do that regardless, and then the clobbering of the file on the next update wouldn't change anything, while the benefit is exactly as you surmised -- there's no danger of having an out-of-sync primary list of renames. A local renames file (or even a renames.d/ directory) should handle the remainder of the valid cases just fine, I think. The benefits of the renames.d/ directory would be similar to the /etc/modprobe.d/ directory -- it would allow for easier maintenance of local rename lists. All that said, I certainly wouldn't change this in the stable branch, and even in svn, my standard disclaimer applies: it's YOUR code. :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chess at chessgriffin.com Thu Apr 30 18:42:10 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Thu, 30 Apr 2009 14:42:10 -0400 Subject: [sbopkg-users] Sbopkg 0.27.2 Released In-Reply-To: <20090430131816.4c767cff@liberty.rlwhome.lan> References: <20090430154431.GA25657@localhost> <20090430123227.7cde87d3@liberty.rlwhome.lan> <20090430180312.GA25687@localhost> <20090430131816.4c767cff@liberty.rlwhome.lan> Message-ID: <20090430184210.GA25764@localhost> * Robby Workman [2009-04-30 13:18:16]: > That the admin might want to get a "head start" on a renamed package > before sbopkg has an updated version is a non-issue; he could do that > regardless, and then the clobbering of the file on the next update > wouldn't change anything, while the benefit is exactly as you surmised > -- there's no danger of having an out-of-sync primary list of renames. > > A local renames file (or even a renames.d/ directory) should handle the > remainder of the valid cases just fine, I think. The benefits of the > renames.d/ directory would be similar to the /etc/modprobe.d/ directory > -- it would allow for easier maintenance of local rename lists. > > All that said, I certainly wouldn't change this in the stable branch, > and even in svn, my standard disclaimer applies: it's YOUR code. :-) > > -RW All excellent points, Robby. I agree that this is something that needs to be looked at and addressed one way or the other. Thanks for bringing it up -- it's now on the TODO. :-) -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: