[arch-dev-public] Questions about Archlinux branding/artwork for KDE
I'm putting together a new package that will contain artwork and branding for KDE. While reviewing the existing kde-common package, I noticed we're also providing defaults for font types and sizes as well as general konqueror settings. I don't plan to include the preferences in the branding package, but I was wondering whether we should be providing these at all. Are the KDE defaults so bad that we need to override them? I figured now would be a good time to discuss this since the existing package will be getting a major overhaul. As far as I can tell, the only things that appear necessary are the kdm rc.d scripts and related environment files...
Am Donnerstag, 29. Mai 2008 01:32:30 schrieb Thayer Williams:
As far as I can tell, the only things that appear necessary are the kdm rc.d scripts and related environment files...
I would say: drop them all. Only the profile.d-env-script is needed. Preconfiguration is not really needed. Imho we should only provide additional themes etc. and not overriding upstream defaults when not necessary. The kdm rc.d scripts could be removed, too. One should start kdm via inittab. Pierre -- archlinux.de
On Wed, May 28, 2008 at 7:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
The kdm rc.d scripts could be removed, too. One should start kdm via inittab.
I think the rc.d method is too widely used to just drop it like that.
On Wed, May 28, 2008 at 4:58 PM, Travis Willard <travis@archlinux.org> wrote:
On Wed, May 28, 2008 at 7:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
The kdm rc.d scripts could be removed, too. One should start kdm via inittab.
I think the rc.d method is too widely used to just drop it like that.
I'm 100% for upstream defaults, but I don't want to be responsible for hundreds of desktops hanging at boot! LOL I assumed that all our desktop managers were tweaked for the rc.d system. Either way, this is a bit out of my league because I have zero experience configuring KDE beyond the basics. The ssh-agent scripts look like they could be moved to a wiki article. As for the rest I'm clueless.
On Wed, May 28, 2008 at 10:45 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Wed, May 28, 2008 at 4:58 PM, Travis Willard <travis@archlinux.org> wrote:
On Wed, May 28, 2008 at 7:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
The kdm rc.d scripts could be removed, too. One should start kdm via inittab.
I think the rc.d method is too widely used to just drop it like that.
I'm 100% for upstream defaults, but I don't want to be responsible for hundreds of desktops hanging at boot! LOL I assumed that all our desktop managers were tweaked for the rc.d system.
Well, they won't hang at boot. There'll be a message like "couldn't find /etc/rc.d/kdm" or something like that and it'll drop people to console login.
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Donnerstag, 29. Mai 2008 01:32:30 schrieb Thayer Williams:
As far as I can tell, the only things that appear necessary are the kdm rc.d scripts and related environment files...
I would say: drop them all. Only the profile.d-env-script is needed. Preconfiguration is not really needed. Imho we should only provide additional themes etc. and not overriding upstream defaults when not necessary. The kdm rc.d scripts could be removed, too. One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
On Thu, May 29, 2008 at 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
Isn't there a little problem here? People should use inittab, yet many people use rc.d scripts. It is probably not a big deal since I guess both methods usually work fine, but maybe it should be somehow made clearer that inittab is the preferred way. For example by deprecating the rc.d scripts and planning a future removal instead of removing them now.
On Fri, May 30, 2008 at 5:57 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, May 29, 2008 at 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
Isn't there a little problem here? People should use inittab, yet many people use rc.d scripts. It is probably not a big deal since I guess both methods usually work fine, but maybe it should be somehow made clearer that inittab is the preferred way. For example by deprecating the rc.d scripts and planning a future removal instead of removing them now.
There are two perspectives- it is a problem, or it is flexible. Some people never want to touch /etc/inittab and do all their config in rc.conf, so the rc.d script works for them. Those that are more interested in the workings of runlevels and init-spawned processes would use inittab. We've always supported both and our overhead is minimal to support it, so we could maybe go and edit the wiki to make it more clear that inittab is the preferred way, but I don't think we should exert more force than that. -Dan
On Fri, May 30, 2008 at 5:57 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, May 29, 2008 at 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
Isn't there a little problem here? People should use inittab, yet many people use rc.d scripts. It is probably not a big deal since I guess both methods usually work fine, but maybe it should be somehow made clearer that inittab is the preferred way. For example by deprecating the rc.d scripts and planning a future removal instead of removing them now.
Who said people should use inittab? Is this documented somewhere as The Only Way To Ever Do Things? I use the slim rc.d script and have for ages. I don't see anything wrong with providing choice.
On Fri, 2008-05-30 at 09:37 -0500, Aaron Griffin wrote:
Who said people should use inittab? Is this documented somewhere as The Only Way To Ever Do Things? I use the slim rc.d script and have for ages. I don't see anything wrong with providing choice.
kdm is a daemon, rc.conf contains a DAEMONS array, so kdm belongs at that place. If the reasoning behind not having a /etc/rc.d script for kdm is that upstream doesn't provide it, we should remove daemon scripts from all our packages because they're provided by us instead of upstream. The only reason I see for using inittab is that you can start in runlevel 2 to avoid starting X. Our simple init implementation doesn't handle runlevels for /etc/rc.d scripts. I agree with keeping the /etc/rc.d/kdm script around. Forcing people to use /etc/inittab is not the way we should go.
So long as *someone* is willing to maintain the the rc.d scripts, I'm fine with keeping them around. Personally, I have always used the inittab method--I think it _is_ documented somewhere as The Best Way To Do Things =) If we ever reach a point where devs don't want to maintain this kind of fluff, we could look at the deprecating the scripts as mentioned. On Fri, May 30, 2008 at 7:37 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, May 30, 2008 at 5:57 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, May 29, 2008 at 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
Isn't there a little problem here? People should use inittab, yet many people use rc.d scripts. It is probably not a big deal since I guess both methods usually work fine, but maybe it should be somehow made clearer that inittab is the preferred way. For example by deprecating the rc.d scripts and planning a future removal instead of removing them now.
Who said people should use inittab? Is this documented somewhere as The Only Way To Ever Do Things? I use the slim rc.d script and have for ages. I don't see anything wrong with providing choice.
On Fri, May 30, 2008 at 7:48 AM, Thayer Williams <thayer@archlinux.org> wrote:
So long as *someone* is willing to maintain the the rc.d scripts, I'm fine with keeping them around. Personally, I have always used the inittab method--I think it _is_ documented somewhere as The Best Way To Do Things =)
If we ever reach a point where devs don't want to maintain this kind of fluff, we could look at the deprecating the scripts as mentioned.
On Fri, May 30, 2008 at 7:37 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, May 30, 2008 at 5:57 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, May 29, 2008 at 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 28, 2008 at 6:57 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
One should start kdm via inittab.
I agree with Pierre, except for the rc.d script point - too many people use it, and all the other login managers have rc.d scripts to.
Isn't there a little problem here? People should use inittab, yet many people use rc.d scripts. It is probably not a big deal since I guess both methods usually work fine, but maybe it should be somehow made clearer that inittab is the preferred way. For example by deprecating the rc.d scripts and planning a future removal instead of removing them now.
Who said people should use inittab? Is this documented somewhere as The Only Way To Ever Do Things? I use the slim rc.d script and have for ages. I don't see anything wrong with providing choice.
Ugh! Sorry for top posting before...my greasemonkey scripts are down at the moment. Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right? I'll be out for the morning, but I'd like to get this wrapped up when I get back.
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
On Fri, May 30, 2008 at 8:00 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer... FYI: I didn't completely gut the PKGBUILD--I only removed the artwork. I don't want Tobias to come back from vacation and find that someone vetted all his work (if it his work). I think the long term goal should be to trim the fat from this package and I'll follow up with Tobias about this when he returns. Now onto Xfce...
On Fri, May 30, 2008 at 1:01 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Fri, May 30, 2008 at 8:00 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer...
Actually, this is one of those packages that could easily be for the 'any' arch. Basically, since it's all scripts, and all of 'em are just copied into the proper locations, you can cheat - change your arch in makepkg.conf, rebuild the package (generating an x86_64 package, which is identical to the i686 one) and upload it, then change back your makepkg.conf Since you're not building any code, this'll work fine.
On Fri, May 30, 2008 at 10:16 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 1:01 PM, Thayer Williams <thayer@archlinux.org> wrote:
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer...
Actually, this is one of those packages that could easily be for the 'any' arch. Basically, since it's all scripts, and all of 'em are just copied into the proper locations, you can cheat - change your arch in makepkg.conf, rebuild the package (generating an x86_64 package, which is identical to the i686 one) and upload it, then change back your makepkg.conf
Since you're not building any code, this'll work fine.
Hah, I had no idea about that! We should add that to the wiki if it's not there already.
On Fri, May 30, 2008 at 12:16 PM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 1:01 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Fri, May 30, 2008 at 8:00 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer...
Actually, this is one of those packages that could easily be for the 'any' arch. Basically, since it's all scripts, and all of 'em are just copied into the proper locations, you can cheat - change your arch in makepkg.conf, rebuild the package (generating an x86_64 package, which is identical to the i686 one) and upload it, then change back your makepkg.conf
Since you're not building any code, this'll work fine.
Yeah yeah I need to work the any arch into these scripts. That's another step down the road.
On Fri, May 30, 2008 at 10:22 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, May 30, 2008 at 12:16 PM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 1:01 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Fri, May 30, 2008 at 8:00 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer...
Actually, this is one of those packages that could easily be for the 'any' arch. Basically, since it's all scripts, and all of 'em are just copied into the proper locations, you can cheat - change your arch in makepkg.conf, rebuild the package (generating an x86_64 package, which is identical to the i686 one) and upload it, then change back your makepkg.conf
Since you're not building any code, this'll work fine.
Yeah yeah I need to work the any arch into these scripts. That's another step down the road.
Could someone paste the exact modifications required in the makepkg.conf? I'll add this to the wiki somewhere.
On Fri, May 30, 2008 at 12:25 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:22 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, May 30, 2008 at 12:16 PM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 1:01 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Fri, May 30, 2008 at 8:00 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 10:55 AM, Thayer Williams <thayer@archlinux.org> wrote:
Does anyone mind if I update the kde-common i686 package to remove the artwork stuff? I see Tobias is the maintainer, but he's currently away right?
I say go for it.
I've updated the kde-common package for i686, but I can't build it for x86_64. I guess it's time to start looking for a 3rd computer...
Actually, this is one of those packages that could easily be for the 'any' arch. Basically, since it's all scripts, and all of 'em are just copied into the proper locations, you can cheat - change your arch in makepkg.conf, rebuild the package (generating an x86_64 package, which is identical to the i686 one) and upload it, then change back your makepkg.conf
Since you're not building any code, this'll work fine.
Yeah yeah I need to work the any arch into these scripts. That's another step down the road.
Could someone paste the exact modifications required in the makepkg.conf? I'll add this to the wiki somewhere.
Erm, it's a bit of a hack, so make sure if you DO add it to the wiki, you slather it in warnings like "OMG please be sure you know what you're doing". Considering this is only scripts, you should only need to change the CARCH variable so that makepkg will generate an x86_64 package. Now, there is actually another way to hack this... you can actually just edit the .PKGINFO file, change the %ARCH% variable, and rename the file. Though, I think, 'extrapkg' would need the makepkg.conf changes in order to upload it properly For the record, vim can open and allow you to edit files in a tarball.
On Fri, May 30, 2008 at 1:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Erm, it's a bit of a hack, so make sure if you DO add it to the wiki, you slather it in warnings like "OMG please be sure you know what you're doing".
Yeah, it's a total hack, this really shouldn't be documented anywhere as an official procedure - s'why I called it "cheating".
On Fri, May 30, 2008 at 10:38 AM, Travis Willard <travis@archlinux.org> wrote:
On Fri, May 30, 2008 at 1:35 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Erm, it's a bit of a hack, so make sure if you DO add it to the wiki, you slather it in warnings like "OMG please be sure you know what you're doing".
Yeah, it's a total hack, this really shouldn't be documented anywhere as an official procedure - s'why I called it "cheating".
Gotcha. I won't bother with documenting it then...especially since we're gonna have the 'any' flag working soon...*ahem* right? =)~
participants (7)
-
Aaron Griffin
-
Dan McGee
-
Jan de Groot
-
Pierre Schmitz
-
Thayer Williams
-
Travis Willard
-
Xavier