Re: [gentoo-dev] New network config for baselayout-ng
On Wednesday 07 February 2007, Roy Marples wrote: > We still need something that is "array like" for want of a better > phrase, so how about delimiting using ; like so > config_eth0="10.1.1.1 netmask 255.255.255.0; 10.1.1.2/24" if you want to allow one liners, then i dont see any other real option ... the semicolon is prob about the best/only choice i'd think if you want to force newlines as the delimiter, then the new format would pretty closely resemble the existing array layout ... config_eth0=" 10.1.1.1 netmask 255.255.255.0 10.1.1.2/24 " -mike pgpe6BObgtkdn.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thursday 08 February 2007, Chris Gianelloni wrote: > He's not "screwing up" anything. He's making changes he wishes as the > author and maintainer of the package. If someone doesn't like it, they > can fork it and maintain their own package. Isn't that just wonderful? > Seriously, Roy can work on whatever he wants how he wants, just like any > of the rest of us. Anyone who doesn't like it can simply fork the > project, or even create a new project to replace the functionality > provided by this package. It happens all the time. I seem to remember > it happening with this package manager we all are familiar with... that really isnt a valid stance to take with the package in question ... by this logic, i can turn around and screw with the toolchain and if no one likes what i'm doing, then that's their problem and they can go fork themselves if people stop thinking of Ciaran as being nothing but a huge dick (which he can be) and read the thread from top to bottom, each of his e-mails in this thread was quite valid it seems the backwards compatibility crowd has won out and the current (quite powerful) format will be supported for those who want it ... and for those who are always looking forward, they shouldnt have a problem either -mike pgpajQEgC6h0T.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Wednesday 07 February 2007, Kevin F. Quinn wrote: > Another idea; have baselayout install different versions of > init.d/conf.d and default shell for runscript depending on USE flags that'll just lead to horrible bit rot and code duplication i would think -mike pgpoE6NHhLauz.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Thursday 08 February 2007, Ned Ludd wrote: > Please read over what's been talked about elsewhere in this thread. He > is not trying to break existing functionality at all. Only extend it to > be posix aware (additionally) erm, no ... our code is a superset of POSIX, so technically yes he is breaking existing functionality and doing the quite opposite of extending -mike pgplxEo0WIAJC.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
He's not going to waste someone else's time, and as he said there will be compatibility with current configuration files, I don't think there's any downside to users. FWIW, speaking as a user, I value stability over speed. But if I have a promise of stability (i.e. my current configs will still work), I have no problem with Roy scratching his speed itch. :) Thanks, Marty -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Friday 09 February 2007, Ned Ludd wrote: > baselayout is only about a half of a meg these days and probably > getting smaller/faster with the addition of the multicall rc/runscript > work he has been doing. > > Adding bash also requires ncurses which in turn mostly requires having > a c++ aware compiler or using the nocxx,minimal flags. Even with those > flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure > see the benefits. > > Also for a moment lets stop and think. Some XYZ update breaks > ncurses/bash. Supporting this gives us a nice alternative way to still > boot our boxes for rescue using ash or another shell which might not > have such big deps. From where I stand I can see Ned's point just fine: I'm interested in both having a sane baselayout that doesn't break on bash upgrade (I've seen the breakage with 3.1, 3.2.. I also masked bash 3.1 while Roy fixed baselayout for that version), and in a baselayout that can run on medium embedded systems (and not just "for fun", trust me), so I wouldn't dismiss Roy's work as "unneeded" and/or not useful to anyone. He's not going to waste someone else's time, and as he said there will be compatibility with current configuration files, I don't think there's any downside to users. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpg13D9POXYc.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Thu, 8 Feb 2007 14:49:57 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: > In other words: > > busybox + single rcS file = fastest and simplest, smallest, best for > very small filesystems, not as flexible > > bash + gentoo baselayout = most flexible, biggest, slower, best for > feature-rich systems > > busybox + gentoo baselayout = ? FreeBSD sh + Gentoo baselayout = cold boot in around 4 seconds Going to multi-user from single user after a boot is under 2 seconds (times measured from when init starts rc - the difference is probably because the all my local mounts are still mounted) I have this running on a 2Ghz P4 Laptop right now. Admittedly, no network scripts are started expect for the loopback interface, but all default scripts + openvpn, ssh, dnsmasq, metalog and vixie-cron are started. Ladies and gentlemen, this has always been about one thing - speed. Ever since I got my 300Mhz Sparc64 to play around with FreeBSD, I've realised that baselayout + bash is just too damn slow. I think that's worth it. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: > On Thu, 08 Feb 2007 09:20:17 -0500 Doug Goldstein <[EMAIL PROTECTED]> > wrote: > | Do *YOU* have anything useful to contribute to the discussion because > | all I've seen is your useless FUD which countless times people have > | said is not true. > > If you bothered to pay attention, you'll note that Roy *didn't* > guarantee compatibility until late on in the discussion, and that he > only started providing that guarantee because of what you're calling > "useless FUD". > If you bothered to pay attention, by the time you sent the e-mail I was previously replying to, Roy had already guaranteed compatibility. So still claiming there was no compatibility is useless FUD. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote: > On 2/8/07, Ned Ludd <[EMAIL PROTECTED]> wrote: > > As somebody that's had to hand write many of those kinds of scripts. A > > single rcS is not very ideal. Our init scripts are in fact mostly usable > > by busybox. Granted there are a few special special cases, but then Roy > > is offering to update those for free. One of the larger problems really > > boils down to many packages provide default init.d scripts and these > > expect the existing baselayout only. That will be a bigger feat to deal > > with later on down the road. > > Developers will then need to test their init.d scripts to ensure that > they are compatible with busybox. This is asking a lot of work of > people just so you can use Gentoo's initscripts for something they are > not really ideal for. I don't think anybody can/would expect that. They don't test for hardened or uClibc now before stabilizing a pkg. What would be nice to see is if a maintainer is offered a posix compliant init.d script that they merge it or allow those to be merged for a pkg they maintain as long as it does not degrade functionality. > Any time a script is updated a new rev of a > package is required, and this does impact users and will cause > packages to be rebuilt when a user does "emerge -u". So I think this > should be weighed against the potential benefits of baselayout + > busybox. busybox is not Roys underlying goal as far as I understand. I think he simply mentioned it as an example of another group who wishes to unify efforts and have an interest in getting away from arrays where feasible. > If you are targetting something smaller than 32MB, then maybe busybox > is appropriate. But you are trying to go really small, then you > probably don't want all the extra junk in our initscripts. And if you > are _not_ trying to go really small, then put bash in your filesystem, > not busybox, and the initscripts will work. If bash isn't fast enough > from a boot time perspective, then the gentoo initscripts certainly > aren't going to be fast enough either. > > In other words: > > busybox + single rcS file = fastest and simplest, smallest, best for > very small filesystems, not as flexible > > bash + gentoo baselayout = most flexible, biggest, slower, best for > feature-rich systems > > busybox + gentoo baselayout = ? It's been done in the past by end users. Before there were only about 4 changes needed to make it work. That all changed when bash arrays were introduced. > I think that in 99 out of 100 cases, if you have room for baselayout, > then you probably have room for bash too. And in 99 out of 100 cases, > if you can deal with the load time of baselayout, then you can deal > with the overhead that might be incurred from having bash. > > I'm just pointing out that it's not an obviously good combination. In > the grand scheme of things, maybe it's not a great use of developer > resources. Or, maybe I'm wrong and it is a great idea. His time and resources. His "itch" > Personally I think that "baselayout + busybox" may be cool, but adding > an aftermarket sunroof to your car can be cool too. But that doesn't > mean it's worth the effort :) I don't think those who are not interested in this will be burden by any extra effort. Worst case is maybe getting a bug assigned to you which offers a posix replacement/update for the default init.d a pkg you maintain might provide. > Really, it's hard for me to imagine many scenarios where you really > need the flexibility of baselayout but can't squeeze in bash. And I > have a pretty good imagination. baselayout is only about a half of a meg these days and probably getting smaller/faster with the addition of the multicall rc/runscript work he has been doing. Adding bash also requires ncurses which in turn mostly requires having a c++ aware compiler or using the nocxx,minimal flags. Even with those flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure see the benefits. Also for a moment lets stop and think. Some XYZ update breaks ncurses/bash. Supporting this gives us a nice alternative way to still boot our boxes for rescue using ash or another shell which might not have such big deps. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] A Gentle Reminder
If any of you were thinking of removing the latest stable version of a package, don't. Even if you're the package maintainer, even if there are open security bugs against it, even if someone has filed you a bug requesting that it be removed. If it's the latest stable version on any architecture, you don't remove it. If you do, we'll know, and we won't be happy. There. It's not that hard to understand, is it? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A major change coming in the rox packages
Diego 'Flameeyes' Pettenò wrote: > On Thursday 08 February 2007, Jim Ramsay wrote: > > How would you then reconcile the issues raised in this bug[1] > > regarding /usr/lib and multilib support? > > /usr/lib/misc most likely, or /usr/libexec as you prefer, considering that > the > policy about that is still unwritten and probably will not appear in the next > few months either. My only fear with going with /usr/lib/misc or /usr/libexec is that the actual move won't be pretty (I'll have to come up with some way for users to migrate some config files), so I'd prefer to only have to do it once. That's why I want to be sure I consider every viable option and pick the best location: so it's less likely I have to do it all again in 6 months. Then again, maybe my migration strategy will be so good it will be easy to do a second time :) -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On 2/8/07, Ned Ludd <[EMAIL PROTECTED]> wrote: As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. Developers will then need to test their init.d scripts to ensure that they are compatible with busybox. This is asking a lot of work of people just so you can use Gentoo's initscripts for something they are not really ideal for. Any time a script is updated a new rev of a package is required, and this does impact users and will cause packages to be rebuilt when a user does "emerge -u". So I think this should be weighed against the potential benefits of baselayout + busybox. If you are targetting something smaller than 32MB, then maybe busybox is appropriate. But you are trying to go really small, then you probably don't want all the extra junk in our initscripts. And if you are _not_ trying to go really small, then put bash in your filesystem, not busybox, and the initscripts will work. If bash isn't fast enough from a boot time perspective, then the gentoo initscripts certainly aren't going to be fast enough either. In other words: busybox + single rcS file = fastest and simplest, smallest, best for very small filesystems, not as flexible bash + gentoo baselayout = most flexible, biggest, slower, best for feature-rich systems busybox + gentoo baselayout = ? I think that in 99 out of 100 cases, if you have room for baselayout, then you probably have room for bash too. And in 99 out of 100 cases, if you can deal with the load time of baselayout, then you can deal with the overhead that might be incurred from having bash. I'm just pointing out that it's not an obviously good combination. In the grand scheme of things, maybe it's not a great use of developer resources. Or, maybe I'm wrong and it is a great idea. Personally I think that "baselayout + busybox" may be cool, but adding an aftermarket sunroof to your car can be cool too. But that doesn't mean it's worth the effort :) Really, it's hard for me to imagine many scenarios where you really need the flexibility of baselayout but can't squeeze in bash. And I have a pretty good imagination. -Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 13:23 -0700, Daniel Robbins wrote: > I sort of missed this conversation, so apologies in advance if this > has already been covered, but wanted to say that gentoo's initscripts > are generally not suited for embedded systems. > > So making baselayout busybox-compatible doesn't seem to be worth the > disruption and headaches it would cause. Please read over what's been talked about elsewhere in this thread. He is not trying to break existing functionality at all. Only extend it to be posix aware (additionally) > It would be disruptive for > gentoo developers who would need to be extra-careful in maintaining > their initscripts to ensure busybox compatibility. Not to mention the > potential disruption for users. There is no reason this has to be disruptive to the users who don't care about this functionality. > If you are building an embedded system using busybox, then generally > you will want a single /etc/init.d/rcS script that starts all the > stuff you need. As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. > -Daniel > > On 2/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Thursday 08 February 2007, Roy Marples wrote: > > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > On Wednesday 07 February 2007, Roy Marples wrote: > > > > > In the current code I'm running it's only the network stuff that > > > > > uses arrays. If you're thinking about /sbin/functions.sh, well that > > > > > can stay as bash as it's not used by baselayout anymore. > > > > > > > > some init.d scripts use arrays as well > > > > > > Do we know which ones? > > > > grep for it :p > > netmount for sure right now > > > > > The actual scripts themselves can be re-worked if they need to be - > > > this problem only when the arrays are used in config files. > > > > i guess my point was i think we really need to be consistent here ... either > > arrays are OK for init.d scripts or they're not OK > > > > did you get a chance to see how hard it would be to integrate the bash array > > code ? > > -mike > > > > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thursday 08 February 2007, Roy Marples wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > did you get a chance to see how hard it would be to integrate the > > bash array code ? > > Integrate into what? You mean integrate into other shells? mmm i thought you were looking to parse the config files directly from baselayout and not via shell, so i was referring to integrating arrays into baselayout -mike pgp6VXSWIz5rl.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
I sort of missed this conversation, so apologies in advance if this has already been covered, but wanted to say that gentoo's initscripts are generally not suited for embedded systems. So making baselayout busybox-compatible doesn't seem to be worth the disruption and headaches it would cause. It would be disruptive for gentoo developers who would need to be extra-careful in maintaining their initscripts to ensure busybox compatibility. Not to mention the potential disruption for users. If you are building an embedded system using busybox, then generally you will want a single /etc/init.d/rcS script that starts all the stuff you need. -Daniel On 2/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Thursday 08 February 2007, Roy Marples wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Wednesday 07 February 2007, Roy Marples wrote: > > > In the current code I'm running it's only the network stuff that > > > uses arrays. If you're thinking about /sbin/functions.sh, well that > > > can stay as bash as it's not used by baselayout anymore. > > > > some init.d scripts use arrays as well > > Do we know which ones? grep for it :p netmount for sure right now > The actual scripts themselves can be re-worked if they need to be - > this problem only when the arrays are used in config files. i guess my point was i think we really need to be consistent here ... either arrays are OK for init.d scripts or they're not OK did you get a chance to see how hard it would be to integrate the bash array code ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 8 Feb 2007 13:01:08 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > some init.d scripts use arrays as well > > > > Do we know which ones? > > grep for it :p > netmount for sure right now Well, netmount is baselayout, so that will kinda be done by default :) > i guess my point was i think we really need to be consistent here ... > either arrays are OK for init.d scripts or they're not OK I say no, as I'd like eventually anything in /etc/init.d,conf.d to be useable by any shell. It's not especially hard to make existing scripts in the tree work either. I'm happy to do this myself. > did you get a chance to see how hard it would be to integrate the > bash array code ? Integrate into what? You mean integrate into other shells? Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] A major change coming in the rox packages
Ed Catmur wrote: > On Thu, 2007-02-08 at 11:05 -0600, Jim Ramsay wrote: > > I am planning on moving the install locations of all the rox-base/* and > > rox-extra/* applications from their current location (/usr/lib/rox) to > > something a little more FHS-correct[1] and tolerant of multilib support. > > Have you considered /usr/lib/misc/rox? Hmmm... that's actually not a bad alternative to /usr/libexec I suppose (though it's also not in the FHS), but will features="multilib-strict" complain when I put rox-clib in /usr/lib/misc/rox/? I suspect it will.[1] So then all I need to do is somehow deal with rox-clib, which may be safe to put in /usr/$(get_libdir), which would satisfy the multilib folks... [1] http://bugs.gentoo.org/show_bug.cgi?id=155983 -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
On Thursday 08 February 2007, Jim Ramsay wrote: > How would you then reconcile the issues raised in this bug[1] > regarding /usr/lib and multilib support? /usr/lib/misc most likely, or /usr/libexec as you prefer, considering that the policy about that is still unwritten and probably will not appear in the next few months either. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpyccEJxAMJ3.pgp Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
Diego 'Flameeyes' Pettenò wrote: > On Thursday 08 February 2007, Thomas Rösner wrote: > > AFAIR App Dirs provide internal arch distinction, so why not just put it > > in /usr/share/rox? > > /usr/share is not a good place for any kind of executable. Also, after compiling the AppDirs (in the few cases where these aren't just python source) I remove the src directory, so it will not be recompiled for other archs. The only thing you get in the appdir as installed by portage is the binary for your arch. In the case of python, maybe this wouldn't matter as much. > /usr/lib is more suitable for the purpose. How would you then reconcile the issues raised in this bug[1] regarding /usr/lib and multilib support? I suppose I still don't know enough about multilib support to know if putting things in /usr/$(get_libdir)/rox would be correct, or if I should just hardcode to /usr/lib and close that bug as INVALID. Then I would have to somehow deal with the special case of rox-clib[2], since it really is a library but it does not have to be in the normal ld search path. I suppose that could actually go in /usr/$(get_libdir) without much trouble. [1] http://bugs.gentoo.org/show_bug.cgi?id=164816 [2] http://bugs.gentoo.org/show_bug.cgi?id=155983 -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
On Thursday 08 February 2007, Thomas Rösner wrote: > AFAIR App Dirs provide internal arch distinction, so why not just put it > in /usr/share/rox? /usr/share is not a good place for any kind of executable. /usr/lib is more suitable for the purpose. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpsHVKNKs8IS.pgp Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
On Thu, 2007-02-08 at 11:05 -0600, Jim Ramsay wrote: > I am planning on moving the install locations of all the rox-base/* and > rox-extra/* applications from their current location (/usr/lib/rox) to > something a little more FHS-correct[1] and tolerant of multilib support. > > The main reason for this change is that I got a bug from amd64 because > the /usr/lib path is hard-coded all over the place (ie, not multilib > compliant), but it's always sort of bugged me that these packages are > in /usr/lib - They're not actually libaries (except for rox-clib). > These rox applications are a new special case that don't fit into the > FHS, called "Application Directories"[2], and I need a good place to > put them. > > Please note that every rox application creates a symlink in /usr/bin > which runs the application regardless of where it exists in the > filesystem, so from an end-user perspective this doesn't really > matter. (Except a small bit of migration when I actually do move these > packages, which will be the topic for another day). > > I'd like input from any interested parties on where the proper > location may be. Here are some ideas with their justifications and > problems, as I see them: > ... Have you considered /usr/lib/misc/rox? Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: > > But hey, I understand you like to go around bashing people. Does doing > so scratch an itch of yours or something? > I guess we all misunderstood. As long everybody won't have additional work (like changing all our systems) I think nobody would complain. If the posix-only baselayout start I hope some automagic conversion script will be provided once the new style doesn't have regressions. (Still I'd rather have a C runscript with only the features we need as fallback) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thursday 08 February 2007, Roy Marples wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Wednesday 07 February 2007, Roy Marples wrote: > > > In the current code I'm running it's only the network stuff that > > > uses arrays. If you're thinking about /sbin/functions.sh, well that > > > can stay as bash as it's not used by baselayout anymore. > > > > some init.d scripts use arrays as well > > Do we know which ones? grep for it :p netmount for sure right now > The actual scripts themselves can be re-worked if they need to be - > this problem only when the arrays are used in config files. i guess my point was i think we really need to be consistent here ... either arrays are OK for init.d scripts or they're not OK did you get a chance to see how hard it would be to integrate the bash array code ? -mike pgpc7BSebhvSu.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thursday 08 February 2007, Donnie Berkholz wrote: > Greg KH wrote: > > On Wed, Feb 07, 2007 at 09:44:20PM -0500, Mike Frysinger wrote: > >> On Wednesday 07 February 2007, Roy Marples wrote: > >>> Welcome to baselayout-ng > >> > >> please god do not use this name ... just call it baselayout-2 > > > > Especially as what will you call the replacement for baselayout-ng? > > baselayout-ng-ng? > > What did they call the Star Trek after NG? =) not worth watching ? -mike pgpt4yQWQvD2A.pgp Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
Jim Ramsay schrieb: I am planning on moving the install locations of all the rox-base/* and rox-extra/* applications from their current location (/usr/lib/rox) to something a little more FHS-correct[1] and tolerant of multilib support. The main reason for this change is that I got a bug from amd64 because the /usr/lib path is hard-coded all over the place (ie, not multilib compliant), but it's always sort of bugged me that these packages are in /usr/lib - They're not actually libaries (except for rox-clib). These rox applications are a new special case that don't fit into the FHS, called "Application Directories"[2], and I need a good place to put them. Let's see, /usr: AFAIR App Dirs provide internal arch distinction, so why not just put it in /usr/share/rox? This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. If you don't follow that rationale, as far as I read the FHS, Rox should stay in /usr/lib/rox: /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. *Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. * Note that in that case, the Help files etc. would be aliens there. The fact that Rox Apps can compile themselves on demand would make them go into /var/, but I trust that all ebuilds precompile everything as needed, so no write access is necessary. If Gentoo hadn't the (useful) binary/from source distinction, I'd vote for opt. I'd like input from any interested parties on where the proper location may be. Here are some ideas with their justifications and problems, as I see them: /usr/libexec/rox - libexec isn't actually in the FHS (that I could see), and /usr/libexec is usually assumed to contain executable code, so it may be a "safe" place to put things. That said, libexec is considered by some to be dead or about to disappear[3], so it may not be the right place to go. If your motivation is FHS, dont use libexec. /usr/rox - This isn't in the FHS either, I would be creating it. The problem is that the FHS specifically says "Large software packages must not use a direct subdirectory under the /usr hierarchy." With a good reason (see below). /usr/bin/rox-desktop - This may be the most correct, since the FHS does allow subdirectories here, and doesn't explicitly prohibit new ones. Also, these are actually executable commands. The problem is that (at least considering my currently installed packages) no one else has created any subdirectories in /usr/bin. I don't know if that's a problem. Also, I can't use the name 'rox' in this place because that conflicts with a filename from rox-base/rox. Everything in /usr/bin is assumed to be a user callable executable. If you follow the notion that an App Dir is a large bin that happens to be in directory form (it could be a .jar, after all), this would make sense. But again, for multiple Archs you'd have tons of duplicates. If you read the FHS and don't concentrate on following it to the letter, though, but read the motivation why it even exists and what it tries to accomplish, namely to make the directory tree shareable as far as possible, I'd really consider /usr/share/rox. If my assumption is correct (that it would work). I guess if you'd ask the FHS guys, they'd say "Chop those app dirs up to the proper locations and symlink them together in one place if needed", which would be much work for little gain. Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 08:06:07 -0800 Josh Saddler <[EMAIL PROTECTED]> wrote: > > Next question, then, since I am extremely, exquisitely glad to know > that the existing, familiar, comfortable, (etc.) way of doing it will > be allowed, how long will that last. That is, will we all be forced to > migrate to the new way of configuring things at some point in the > future, or is that so far off yet that we needn't worry? I'm wondering > if you see us all switching at some point, say, 6 - 9 months down the > road. How long are you willing to support the status quo? They'll stay put as they are in there present form until they just stop working for whatever reason. Minor bugs will probably be fixed, but no new feature additions will happen. Of course, anyone is welcome to step up and maintain bash style configs and their scriplets if they so wish. I don't give out time scales :) Thanks Roy -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] A major change coming in the rox packages
I am planning on moving the install locations of all the rox-base/* and rox-extra/* applications from their current location (/usr/lib/rox) to something a little more FHS-correct[1] and tolerant of multilib support. The main reason for this change is that I got a bug from amd64 because the /usr/lib path is hard-coded all over the place (ie, not multilib compliant), but it's always sort of bugged me that these packages are in /usr/lib - They're not actually libaries (except for rox-clib). These rox applications are a new special case that don't fit into the FHS, called "Application Directories"[2], and I need a good place to put them. Please note that every rox application creates a symlink in /usr/bin which runs the application regardless of where it exists in the filesystem, so from an end-user perspective this doesn't really matter. (Except a small bit of migration when I actually do move these packages, which will be the topic for another day). I'd like input from any interested parties on where the proper location may be. Here are some ideas with their justifications and problems, as I see them: /usr/libexec/rox - libexec isn't actually in the FHS (that I could see), and /usr/libexec is usually assumed to contain executable code, so it may be a "safe" place to put things. That said, libexec is considered by some to be dead or about to disappear[3], so it may not be the right place to go. /usr/rox - This isn't in the FHS either, I would be creating it. The problem is that the FHS specifically says "Large software packages must not use a direct subdirectory under the /usr hierarchy." /opt/rox - This is FHS-safe, but the gentoo convention is to reserve /opt for binary packages only, and these appdirs are not. /usr/bin/rox-desktop - This may be the most correct, since the FHS does allow subdirectories here, and doesn't explicitly prohibit new ones. Also, these are actually executable commands. The problem is that (at least considering my currently installed packages) no one else has created any subdirectories in /usr/bin. I don't know if that's a problem. Also, I can't use the name 'rox' in this place because that conflicts with a filename from rox-base/rox. I'm currently tending toward one of the last two, but am open to suggestions to persuade me toward or away from any of these, or any other, better suggestion. Inside this new location I will be further reorganizing the packages so most apps will be inside an 'Apps' subdirectory of this new location, and rox-lib will be in a 'lib' subdirectory. Now, one last thing to consider is rox-clib, which is actually a C library. However, thanks to the way rox software works with application directories, it doesn't need to be in the normal library search path at all to function properly. I think that it would make sense then for me to also take it out of /usr/lib altogether, and instead put it alongside rox-lib in the new location. It already has an internal directory structure that provides a unique location for any 32- versus 64-bit versions of itself. Thanks for your help! [1] http://www.pathname.com/fhs/ [2] http://rox.sourceforge.net/desktop/AppDirs [3] http://article.gmane.org/gmane.linux.gentoo.devel/44751 (and others) -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
Roy Marples wrote: > On Thu, 08 Feb 2007 14:26:40 +0100 > Francesco Riosa <[EMAIL PROTECTED]> wrote: >> lol, >> anyway stop this thread, Roy stated that the installed cfg files will >> be managed via use flags that would satisfy everyone. > > I say maybe a USE flag or something else. May not need one, we'll see. > Existing configs will be supported somehow, don't worry about that. > > Thanks Okay, USE flags are one idea; I can see how that would make maintenance a little easier than having two separate baselayout ebuilds; just have a posix USE flag rather than calling it baselayout-posix or whatever. Next question, then, since I am extremely, exquisitely glad to know that the existing, familiar, comfortable, (etc.) way of doing it will be allowed, how long will that last. That is, will we all be forced to migrate to the new way of configuring things at some point in the future, or is that so far off yet that we needn't worry? I'm wondering if you see us all switching at some point, say, 6 - 9 months down the road. How long are you willing to support the status quo? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh schrieb: On Thu, 08 Feb 2007 09:20:17 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: | Do *YOU* have anything useful to contribute to the discussion because | all I've seen is your useless FUD which countless times people have | said is not true. I can count to one. If you bothered to pay attention, you'll note that Roy *didn't* guarantee compatibility until late on in the discussion, and that he only started providing that guarantee because of what you're calling "useless FUD". And I'm personally thankful that backwards compatibility is now guaranteed and it's actually bad that people have to raise a stink to get that promise. If you break my net config files (again), I'll scratch your itch for good. Regards, Thomas, today's representitive of Evil Admins Group -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 8 Feb 2007 14:28:52 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Thu, 08 Feb 2007 09:20:17 -0500 Doug Goldstein <[EMAIL PROTECTED]> > wrote: > | Do *YOU* have anything useful to contribute to the discussion > because | all I've seen is your useless FUD which countless times > people have | said is not true. > > If you bothered to pay attention, you'll note that Roy *didn't* > guarantee compatibility until late on in the discussion, and that he > only started providing that guarantee because of what you're calling > "useless FUD". > > What remains is the larger issue of whether "I want to scratch an > itch" is sufficient justification for doing whatever one wants. To > quote ferdy: > > "mmm since these kde ebuilds are itching me a lot... am I free to cvs > remove them to scratch it?" > While we're at it, I've got an itch to remove gnome from the tree. Can I do it? Please? Pretty please? Seriously everyone, take a step back and forget the fact that you are talking to Ciaran, and consider only the point he is trying to make. Is "scratching an itch" justification to make radical changes that will affect *all* users of Gentoo? I don't think it is unreasonable to demand a well-thought out explanation that describes precisely the problems that are solved, the the problems that are created, and the implications. I'm sorry, but "I want to scratch an itch" isn't a reasonable explanation. It's a cop-out. -Steve P.S. Before anyone decides to make a counter-point with paludis again, nobody is forcing anyone to use that. If baselayout is changed, everyone is *forced* to use it. signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion
Chris Gianelloni wrote: On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote: That is enough once you know how to write ebuilds. We were thinking of a GUI to soften the learning curve to non-experts. Probably not useful for a Gentoo developer, but could provide an easy way to write ebuilds to project maintainers themselves, not to Gentoo resources. I think what everyone means here is that if the default functions don't cover it, and an eclass doesn't cover it, then all of the code will have to be written by hand, anyway. No amount of pretty clicky interfaces will help this. The only thing I would really see as being useful would be a simple help system that is aware of all of the functions in ebuilds. This could be possible if there were some standardized way to document functions and their uses, so it could be parsed at run-time from the tree itself, but currently, I don't see it getting much traction. Don't get me wrong, I see lots of places where work could be done to make things easier, such as some way to easily determine dependencies. I just don't think it is possible to write up an IDE until more work is done defining the current eclasses and functions into something more static. It'd be very difficult to replace just 'opening a text editor' by an IDE. Though you might probably come up with very cool ideas ; like for example, an eclass browser that could search function based on name or descriptions of what the developer is looking for; probably with some hierarchy view for surfing them. At the end, i guess a text editor would be the best option; but that doesn't mean you can't try new methods/ideas. Regards, -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 09:17:58 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > On Thu, 08 Feb 2007 07:32:45 -0500 Chris Gianelloni | > <[EMAIL PROTECTED]> wrote: | > | Actually, that's one of the joys of open source. There *doesn't* | > | need to be *any* justification *whatsoever* for Roy to do | > | anything he likes. After all, that's how many projects start | > | out. Someone decides they want to do something and they start | > | working on it. | > | > Does that extend to someone causing huge tree breakage and massive | > amounts of work for other people because they want to support a | > minority proprietary platform that ships with all kinds of cripped | > and non-GNU core tools? | > | | Yes. And now you're just spreading FUD because Roy clearly said none | of that would happen, so it's pointless to even try to go that route | with your FUD. Which is irrelevant to the discussion about what is acceptable when "scratching an itch". And what you are dismissing as "FUD" is in fact what stopped a change that would royally piss off an awful lot of users. But hey, I understand you like to go around bashing people. Does doing so scratch an itch of yours or something? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 09:20:17 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: | Do *YOU* have anything useful to contribute to the discussion because | all I've seen is your useless FUD which countless times people have | said is not true. If you bothered to pay attention, you'll note that Roy *didn't* guarantee compatibility until late on in the discussion, and that he only started providing that guarantee because of what you're calling "useless FUD". What remains is the larger issue of whether "I want to scratch an itch" is sufficient justification for doing whatever one wants. To quote ferdy: "mmm since these kde ebuilds are itching me a lot... am I free to cvs remove them to scratch it?" -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 14:26:40 +0100 Francesco Riosa <[EMAIL PROTECTED]> wrote: > > lol, > anyway stop this thread, Roy stated that the installed cfg files will > be managed via use flags that would satisfy everyone. I say maybe a USE flag or something else. May not need one, we'll see. Existing configs will be supported somehow, don't worry about that. Thanks -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thursday 08 February 2007 14:20, Doug Goldstein wrote: > Ciaran McCreesh wrote: > > On Thu, 8 Feb 2007 14:13:37 +0100 Wernfried Haas <[EMAIL PROTECTED]> > > > > wrote: > > | On Thu, Feb 08, 2007 at 12:45:30PM +, Ciaran McCreesh wrote: > > | > Ooh, an ad hominem! > > | > > | Is that the name of paludis' bug reporting tool? > > > > No, that would be trac, as you know fine well. Do you have anything > > useful to contribute to the discussion? > > Do *YOU* have anything useful to contribute to the discussion because > all I've seen is your useless FUD which countless times people have said > is not true. Wow, you gentoo devs really do like a good bitching... ;-) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: > On Thu, 8 Feb 2007 14:13:37 +0100 Wernfried Haas <[EMAIL PROTECTED]> > wrote: > | On Thu, Feb 08, 2007 at 12:45:30PM +, Ciaran McCreesh wrote: > | > Ooh, an ad hominem! > | > | Is that the name of paludis' bug reporting tool? > > No, that would be trac, as you know fine well. Do you have anything > useful to contribute to the discussion? > Do *YOU* have anything useful to contribute to the discussion because all I've seen is your useless FUD which countless times people have said is not true. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
frilled wrote: >>> Which is all very well, but not sufficient reason to screw up a project >>> that is developed and used by a lot of people. >>> >> As if we were all gonna die without bash arrays in our config files. >> > > > And once again nobody thinks of the user base. Changing configuration > file syntax means admins have to edit stuff with _no_ apparent benefit > on the user side. It costs time and opens up new opportunities for > problems. Maybe you don't mind doing it on a handful of home boxes. If > you manage a lot of servers, you'll probably think different. > Personally, constantly having to change stuff that does not benefit me > is a hell of an annoyance to me. > > Regards, > > frilled > Once again, he said the old config would work and there would be a newer format that would not require bash as well. So the user base is handled. Stop joining the FUD bandwagon. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: > On Thu, 08 Feb 2007 07:32:45 -0500 Chris Gianelloni > <[EMAIL PROTECTED]> wrote: > | Actually, that's one of the joys of open source. There *doesn't* need > | to be *any* justification *whatsoever* for Roy to do anything he > | likes. After all, that's how many projects start out. Someone > | decides they want to do something and they start working on it. > > Does that extend to someone causing huge tree breakage and massive > amounts of work for other people because they want to support a minority > proprietary platform that ships with all kinds of cripped and non-GNU > core tools? > Yes. And now you're just spreading FUD because Roy clearly said none of that would happen, so it's pointless to even try to go that route with your FUD. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
Wernfried Haas ha scritto: On Thu, Feb 08, 2007 at 12:45:30PM +, Ciaran McCreesh wrote: Ooh, an ad hominem! Is that the name of paludis' bug reporting tool? lol, anyway stop this thread, Roy stated that the installed cfg files will be managed via use flags that would satisfy everyone. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion
Christopher Covington wrote: Apropos ebuild-aware text editor, has anyone written an eclipse plugin yet? I find that setting up ebuild as an external tool is basically all I need but syntax highlighting and eclass reference would make things prettier. I have no idea of the status, but I recently heard about: http://sourceforge.net/projects/geclipse/ -- Joshua Nichols Gentoo/Java Project Lead Gentoo/Xfce Project Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 8 Feb 2007 14:13:37 +0100 Wernfried Haas <[EMAIL PROTECTED]> wrote: | On Thu, Feb 08, 2007 at 12:45:30PM +, Ciaran McCreesh wrote: | > Ooh, an ad hominem! | | Is that the name of paludis' bug reporting tool? No, that would be trac, as you know fine well. Do you have anything useful to contribute to the discussion? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, Feb 08, 2007 at 12:45:30PM +, Ciaran McCreesh wrote: > Ooh, an ad hominem! Is that the name of paludis' bug reporting tool? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpmVi8GZwueT.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion
On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote: > That is enough once you know how to write ebuilds. > > We were thinking of a GUI to soften the learning curve to non-experts. > Probably not useful for a Gentoo developer, but could provide an easy way to > write ebuilds to project maintainers themselves, not to Gentoo resources. I think what everyone means here is that if the default functions don't cover it, and an eclass doesn't cover it, then all of the code will have to be written by hand, anyway. No amount of pretty clicky interfaces will help this. The only thing I would really see as being useful would be a simple help system that is aware of all of the functions in ebuilds. This could be possible if there were some standardized way to document functions and their uses, so it could be parsed at run-time from the tree itself, but currently, I don't see it getting much traction. Don't get me wrong, I see lots of places where work could be done to make things easier, such as some way to easily determine dependencies. I just don't think it is possible to write up an IDE until more work is done defining the current eclasses and functions into something more static. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 07:32:45 -0500 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | Actually, that's one of the joys of open source. There *doesn't* need | to be *any* justification *whatsoever* for Roy to do anything he | likes. After all, that's how many projects start out. Someone | decides they want to do something and they start working on it. Does that extend to someone causing huge tree breakage and massive amounts of work for other people because they want to support a minority proprietary platform that ships with all kinds of cripped and non-GNU core tools? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 07:28:34 -0500 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | He's not "screwing up" anything. He's making changes he wishes as the | author and maintainer of the package. If someone doesn't like it, | they can fork it and maintain their own package. Isn't that just | wonderful? Forking is a rather extreme option, not something one does on a whim... | Seriously, Roy can work on whatever he wants how he wants, | just like any of the rest of us. Anyone who doesn't like it can | simply fork the project, or even create a new project to replace the | functionality provided by this package. Except we already know that that's not the case. Take, for example, the non-GNU-utility changes that the ppc-macos people tried to force upon Gentoo. It's a fairly obvious example of how people cannot and should not be allowed to screw things up just because they want to scratch an itch. | It happens all the time. I seem to remember it happening with this | package manager we all are familiar with... Ooh, an ad hominem! -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thursday 08 February 2007, Krzysiek Pawlik wrote: > Deep Space Nine, then Voyager, then Enterprise... sounds good to me ;) > baselayout-deep-space-nine ;) Portage would hate such versioning scheme ;) I would love it, it would be perfect with the naming convention I'm using for my boxes :) /me points to the @enterprise.flameeyes.is-a-geek.org message-id ;) -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp6jVcUcQ9oH.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 2007-02-08 at 10:38 +, Ciaran McCreesh wrote: > On Thu, 08 Feb 2007 11:32:20 +0100 Simon Stelling <[EMAIL PROTECTED]> > wrote: > | Ciaran McCreesh wrote: > | > Which is all very well, but not sufficient reason to screw up a > | > project that is developed and used by a lot of people. > | > | As if we were all gonna die without bash arrays in our config files. > > If you'd care to read the thread, you'd see that rather a lot of people > are making use of that functionality. There needs to be a better reason > for changing it (again) than "three people are using Gentoo well outside > of what it's designed to do and don't want to install bash". Actually, that's one of the joys of open source. There *doesn't* need to be *any* justification *whatsoever* for Roy to do anything he likes. After all, that's how many projects start out. Someone decides they want to do something and they start working on it. We're all volunteers here. We work on what we want. If you (or anyone, this isn't directed at you, specifically) don't like it, you're more than welcome to try to convince Roy to not do it. I'm sure he takes large monetary bribes. Otherwise, shut your pie hole or fork the current baselayout yourself. Anything else is just you trying to control what Roy does with his completely volunteer time, which is about as likely as me flying a cheese grater to the moon. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 2007-02-08 at 08:18 +, Ciaran McCreesh wrote: > On Wed, 07 Feb 2007 22:58:20 -0500 Doug Goldstein <[EMAIL PROTECTED]> > wrote: > | > A far better justification than you've given currently. > | > | How about hacking on open source is done so that people can scratch > | an itch. No developer has to be a slave to the demands of others if > | it doesn't scratch that developer's itch. > | > | A baselayout without bash scratches Roy's itch. > > Which is all very well, but not sufficient reason to screw up a project > that is developed and used by a lot of people. He's not "screwing up" anything. He's making changes he wishes as the author and maintainer of the package. If someone doesn't like it, they can fork it and maintain their own package. Isn't that just wonderful? Seriously, Roy can work on whatever he wants how he wants, just like any of the rest of us. Anyone who doesn't like it can simply fork the project, or even create a new project to replace the functionality provided by this package. It happens all the time. I seem to remember it happening with this package manager we all are familiar with... -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, Feb 08, 2007 at 11:02:38AM +, Roy Marples wrote: > Who said that there would be loss of functionality? > > I'm just suggesting a new config while supporting the old one. That sounds great, especially for all the slackers unwilling to change their config files. :-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpOpIxtEqxYR.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 8 Feb 2007 10:38:04 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Thu, 08 Feb 2007 11:32:20 +0100 Simon Stelling <[EMAIL PROTECTED]> > wrote: > | Ciaran McCreesh wrote: > | > Which is all very well, but not sufficient reason to screw up a > | > project that is developed and used by a lot of people. > | > | As if we were all gonna die without bash arrays in our config files. > > If you'd care to read the thread, you'd see that rather a lot of > people are making use of that functionality. There needs to be a > better reason for changing it (again) than "three people are using > Gentoo well outside of what it's designed to do and don't want to > install bash". Who said that there would be loss of functionality? I'm just suggesting a new config while supporting the old one. old config requires bash - and as Gentoo/Linux installed /bin/sh as symlink to bash it will still work. Obviously there would be some sort of setting to handle this. At this point I'm favouring a USE flag which controls which net scripts get installed. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion
That is enough once you know how to write ebuilds. We were thinking of a GUI to soften the learning curve to non-experts. Probably not useful for a Gentoo developer, but could provide an easy way to write ebuilds to project maintainers themselves, not to Gentoo resources. On Thursday 08 February 2007 10:43, Ciaran McCreesh wrote: > On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro > > <[EMAIL PROTECTED]> wrote: > | A friend of mine and myself are willing to develop some tools to help > | ebuild development. > > All the common cases should be handled by default functions, package > manager functions and eclasses. Thus, writing ebuilds should consist > merely of handling unique or uncommon special cases, and the best tool > for doing that is an ebuild-aware text editor. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion
Apropos ebuild-aware text editor, has anyone written an eclipse plugin yet? I find that setting up ebuild as an external tool is basically all I need but syntax highlighting and eclass reference would make things prettier. On 2/8/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro <[EMAIL PROTECTED]> wrote: | A friend of mine and myself are willing to develop some tools to help | ebuild development. All the common cases should be handled by default functions, package manager functions and eclasses. Thus, writing ebuilds should consist merely of handling unique or uncommon special cases, and the best tool for doing that is an ebuild-aware text editor. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
> >> Which is all very well, but not sufficient reason to screw up a project >> that is developed and used by a lot of people. >> > > As if we were all gonna die without bash arrays in our config files. > And once again nobody thinks of the user base. Changing configuration file syntax means admins have to edit stuff with _no_ apparent benefit on the user side. It costs time and opens up new opportunities for problems. Maybe you don't mind doing it on a handful of home boxes. If you manage a lot of servers, you'll probably think different. Personally, constantly having to change stuff that does not benefit me is a hell of an annoyance to me. Regards, frilled -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion
On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
> Hi all,
>
> A friend of mine and myself are willing to develop some tools to help
> ebuild development.
>
> We have some constraints, but we are thinking on something like:
> 1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
> 1.1) Where are the sources?
> 1.2) Decompression algorithm?
> 1.3) Compile the sources?
> 1.4) Install man page(s)?
> 1.5) Install documentation?
> 1.6) Bind actions to USE flags?
> It would probably be interesting to define a set of pre-defined categories:
> standard GNU Autotools projects, perl/CPAN modules, python, ...
I see no reason why a good template and/or eclass can't handle this
>
> 2) A tool to deal with the unstandarized way to compile and install Java
> projects. The idea is to write a tool to try to find out:
> 2.1) Where are located the "main" .java sources.
> 2.2) Where are located the unit tests.
> 2.3) Where are the jar files generated (in case of Ant-based builds) when
> the project is built.
> 2.4) Where to get the dependencies.
> And once this information is available, fill the blanks of a pre-defined
> Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
> would allow compilation flags even if the original build mechanism didn't.
> We probably will ask for this specific issue to gentoo-java mailing list.
> We don't think a fully-automated tool is feasible to cope with all kind of
> projects, but we hope it could be of use for Java developers who don't use
> Gentoo but find interesting to get an ebuild with little effort.
I apologies as this will be critical.
Firstly I would be very interested in how you would handle to dependencies of
a package within this build system. Maven is natorious for wanting to
download its dependencies (including plugins all its plugins) from a remote
repository. Something that the java team (and me personally) have been
struggling with for sometime.
Secondly the java-*-2 eclasses are now very advanced wrt everything ant.
They abstract a large portion of the functionality away from the ebuild
(without lossing the flexability)
So here an anottated vim template that I currently use and that will hopefully
( bug #164953 ) make it into the tree.
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
JAVA_PKG_IUSE="doc source" #this appends the appropriate deps to
#DEPEND(RDEPEND) for
source
inherit java-pkg-2 java-ant-2
DESCRIPTION=""
HOMEPAGE=""
SRC_URI="${P}.zip"
LICENSE=""
SLOT="0"
KEYWORDS="~amd64"
IUSE=""
COMMON_DEP=""
RDEPEND=">=virtual/jre-1.4 #this is used by eclasses to determine the target
class version
${COMMON_DEP}"
DEPEND=">=virtual/jdk-1.4#and this determines the source target
app-arch/unzip
${COMMON_DEP}"
EANT_BUILD_TARGET=""
EANT_DOC_TARGET=""
src_install() {
java-pkg_dojar "${PN}.jar"
use doc && java-pkg_dojavadoc build/javadoc
use source && java-pkg_dosrc src
}
I find this ebuild template usually provides everything a java ebuild
requires.
I would suggest you read the dev notes on the gentoo-java project page as well
as reading the wiki.
>
> However, we are just in the definition stage. We haven't decided anything
> yet, and would like to know your suggestions, even if they aren't
> encouraging :).
>
> Thank you very much.
> Jose.
Please don't let me discourage you. I would be very interested in your
solutions for using maven and I believe the when 2.0.5 is released some form
of pom re-writing could be possible (similar to what happens with build.xml
files at the moment), but I dont believe there is a need to mavenify ant
builds. I believe it would be over complicated and have huge problems
handling where the src and libraries within a package reside. When it comes
to ant (at least) I believe the present solution is far more adaptable and
productive.
Alistair
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Thu, 08 Feb 2007 11:32:20 +0100 Simon Stelling <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > Which is all very well, but not sufficient reason to screw up a | > project that is developed and used by a lot of people. | | As if we were all gonna die without bash arrays in our config files. If you'd care to read the thread, you'd see that rather a lot of people are making use of that functionality. There needs to be a better reason for changing it (again) than "three people are using Gentoo well outside of what it's designed to do and don't want to install bash". -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
Ciaran McCreesh wrote: > Which is all very well, but not sufficient reason to screw up a project > that is developed and used by a lot of people. As if we were all gonna die without bash arrays in our config files. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Wed, 7 Feb 2007 23:42:14 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Wednesday 07 February 2007, Roy Marples wrote: > > In the current code I'm running it's only the network stuff that > > uses arrays. If you're thinking about /sbin/functions.sh, well that > > can stay as bash as it's not used by baselayout anymore. > > some init.d scripts use arrays as well > -mike Do we know which ones? The actual scripts themselves can be re-worked if they need to be - this problem only when the arrays are used in config files. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion
On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro <[EMAIL PROTECTED]> wrote: | A friend of mine and myself are willing to develop some tools to help | ebuild development. All the common cases should be handled by default functions, package manager functions and eclasses. Thus, writing ebuilds should consist merely of handling unique or uncommon special cases, and the best tool for doing that is an ebuild-aware text editor. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
[gentoo-dev] Suggestion
Hi all, A friend of mine and myself are willing to develop some tools to help ebuild development. We have some constraints, but we are thinking on something like: 1) A tool to ease writing ebuilds. It would take some parameters, i.e.: 1.1) Where are the sources? 1.2) Decompression algorithm? 1.3) Compile the sources? 1.4) Install man page(s)? 1.5) Install documentation? 1.6) Bind actions to USE flags? It would probably be interesting to define a set of pre-defined categories: standard GNU Autotools projects, perl/CPAN modules, python, ... 2) A tool to deal with the unstandarized way to compile and install Java projects. The idea is to write a tool to try to find out: 2.1) Where are located the "main" .java sources. 2.2) Where are located the unit tests. 2.3) Where are the jar files generated (in case of Ant-based builds) when the project is built. 2.4) Where to get the dependencies. And once this information is available, fill the blanks of a pre-defined Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it would allow compilation flags even if the original build mechanism didn't. We probably will ask for this specific issue to gentoo-java mailing list. We don't think a fully-automated tool is feasible to cope with all kind of projects, but we hope it could be of use for Java developers who don't use Gentoo but find interesting to get an ebuild with little effort. However, we are just in the definition stage. We haven't decided anything yet, and would like to know your suggestions, even if they aren't encouraging :). Thank you very much. Jose. pgpnYTOLxqU3C.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
Donnie Berkholz wrote: Welcome to baselayout-ng >>> please god do not use this name ... just call it baselayout-2 >> Especially as what will you call the replacement for baselayout-ng? >> baselayout-ng-ng? > > What did they call the Star Trek after NG? =) Deep Space Nine, then Voyager, then Enterprise... sounds good to me ;) baselayout-deep-space-nine ;) Portage would hate such versioning scheme ;) -- Krzysiek Pawlik key id: 0xBC51 desktop-misc, desktop-dock, x86, java, apache, ppc... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
Greg KH wrote: > On Wed, Feb 07, 2007 at 09:44:20PM -0500, Mike Frysinger wrote: >> On Wednesday 07 February 2007, Roy Marples wrote: >>> Welcome to baselayout-ng >> please god do not use this name ... just call it baselayout-2 > > Especially as what will you call the replacement for baselayout-ng? > baselayout-ng-ng? What did they call the Star Trek after NG? =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New network config for baselayout-ng
On Wed, 07 Feb 2007 22:58:20 -0500 Doug Goldstein <[EMAIL PROTECTED]> wrote: | > A far better justification than you've given currently. | | How about hacking on open source is done so that people can scratch | an itch. No developer has to be a slave to the demands of others if | it doesn't scratch that developer's itch. | | A baselayout without bash scratches Roy's itch. Which is all very well, but not sufficient reason to screw up a project that is developed and used by a lot of people. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
