You are not logged in.
i'm board, hah
A non-board person would not have had time to post "You guys are retarded!" lol
I AM bored.
Offline
i meant like plywood.... or maybe maple or cedar
Offline
This is now the official "I'm bored/board out of mind thread."
Offline
Thread hijack!
Where's that Dusty at....
Offline
This is now the official "I'm bored/board out of mind thread."
Maybe soon we will get the record of a "complete topic switch in an unrelated title that is also one of the largest threads of bored people."
That is a long record title! lol
Offline
You have a point... The .desktop thing is not a big problem.
Yes, people fetched the littlest issue. The bigger ones, to ceep clean folder structures, are not discussed. To refresh input:
What is /udev for? It is empty, why is it there?
Why are only some configurations placed inside /etc/conf.d, while others are spread?
Why are additional pixmaps spread all over the disc, and not concentrated in /usr/share/pixmap?
...
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
What is /udev for? It is empty, why is it there?
Good question... not sure myself
Why are only some configurations placed inside /etc/conf.d, while others are spread?
/etc/conf.d is for distro specific configurations. That is /etc/conf.d/wireless has nothing to do with anything besides archlinux, while /etc/vimrc is valid for any distro.
Why are additional pixmaps spread all over the disc, and not concentrated in /usr/share/pixmap?
Another thing I never messed with so probably couldn't give you input... again, it may be best to post bugs for specific packages to the bug tracker.
Offline
Pink Chick wrote:Why are additional pixmaps spread all over the disc, and not concentrated in /usr/share/pixmap?
Another thing I never messed with so probably couldn't give you input... again, it may be best to post bugs for specific packages to the bug tracker.
This way, ArchLinux will soon turn into something like a lite SuSE or something. I believe these bugs should be sent UPSTREAM, to the authors of the programs themselves.
Another attitude I've noticed: oh, that package does not have a ./configure script capable of changing the install dir/root => let us fix the hardcoded paths => everything builds ok, yay => we're so cool/better we've hacked this.
With this kind of I'll-fix-it-ONLY-for-my-distro feeling, no wonder Linux is moving slow on adoption to Desktop computers. It's all about collaboration!!! Distro<->source packages collaboration.
Well, these are tonight's thoughts...
Tomorrow will be better.
:: / my web presence
Offline
Another attitude I've noticed: oh, that package does not have a ./configure script capable of changing the install dir/root => let us fix the hardcoded paths => everything builds ok, yay => we're so cool/better we've hacked this.
I completely see your point but I'd like you to pose a WORKABLE solution!
Offline
IceRAM wrote:Another attitude I've noticed: oh, that package does not have a ./configure script capable of changing the install dir/root => let us fix the hardcoded paths => everything builds ok, yay => we're so cool/better we've hacked this.
I completely see your point but I'd like you to pose a WORKABLE solution!
Well, I might have not been very clear: the solutions currently implemented (for any case I've stated) are WORKABLE, but they should not be considered final (as I have the feeling this is happening).
Any problem involving the placement of some files in the filesystem should not be hacked, but should be available through ./configure options. Some of the problems (such as the pixmap locations) should not even be configurable, since there's a standard, if I'm not mistaken.
This is why most of these problems should ALSO be reported upstream. This is one small step destined to make all Linux users' lives better.
:: / my web presence
Offline
In how many of these cases would we be reporting to people upstream who could not be bothered, or did not have the ability, to create a decent install pkg in the first place? And who picks up that slack? And what if the project is dead?
Offline
In how many of these cases would we be reporting to people upstream who could not be bothered, or did not have the ability, to create a decent install pkg in the first place? And who picks up that slack? And what if the project is dead?
In all these situations the WORKABLE solution could be the final one. It wouldn't hurt though mentioning in the PKGBUILD that the maintainer tried contacting the author to fix a packaging bug (date, e-mail of the author etc.) just for the record (this could become a packaging guideline).
I don't like packagers to feel responsable for fixing every broken package. I consider that simply mentioning that "hey, I've tried contacting the author but he didn't respond" could be a sign for the users to drop that package and look for alternatives (if any).
Extra note: I've just remembered that, some days ago, somebody was asking for .desktop files for whatever application - he was asked to bug-report it if I remember well. That is also bad attitude.
P.S. I don't want to know how a PKGBUILD would look if pacman was used on SuSE for example. I think they do tons of patching to fix all these minor glitches and only a few are reported upstream.
Users should be aware that packagers PACK programs for a distribution. FIXING is not in the job description of a packager (which actually represents the distro itself) unless that's a critical.
:: / my web presence
Offline
Users should be aware that packagers PACK programs for a distribution. FIXING is not in the job description of a packager (which actually represents the distro itself) unless that's a critical.
perfectly phrased
Offline
Well put IceRAM...I hadn't really thought of it in that way before.
Offline
I haven't commented at all on this topic, but don't really feel like we are in a circus.
I was kind of hitting on how crisis was misspelled. I usually don't fluke up a word twice the same way unless it is forced. Oh well, you guys are on a different subject anyway.
Offline
This way, ArchLinux will soon turn into something like a lite SuSE or something.
I don't see that.
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
IceRAM wrote:This way, ArchLinux will soon turn into something like a lite SuSE or something.
I don't see that.
Don't take it out of context:
phrakture wrote:Pink Chick wrote:Why are additional pixmaps spread all over the disc, and not concentrated in /usr/share/pixmap?
Another thing I never messed with so probably couldn't give you input... again, it may be best to post bugs for specific packages to the bug tracker.
This way, ArchLinux will soon turn into something like a lite SuSE or something. I believe these bugs should be sent UPSTREAM, to the authors of the programs themselves.
:: / my web presence
Offline
I will not bug report this things, if a guideline coudl fix it in the future.
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
I will not bug report this things, if a guideline coudl fix it in the future.
In other words, you talk a lot but do little?
Examples of things you could do:
* write a draft of the guidelines you propose and submit to the packagers.
* start converting a few packages to the guidelines you request to see how much work it is.
* edit the wiki guidelines to address specific issues
I wrote a java packaging standard and started converting packages only to find that the guidelines are not workable and need revision (which I should get to tomorrow... maybe). Trying to take apart a package and move stuff around is a lot of work, and things break.
Dusty
Offline
Pink Chick wrote:I will not bug report this things, if a guideline coudl fix it in the future.
In other words, you talk a lot but do little?
Boa, Dusty
No.
First of all, I was asking for gnome specials for doing packages, and shared 2 packagebuilds in this forums. I had little response. Then I checked different packages in the repositories to have a look for consistence, and found only few, checked the aur and the guidelines, and noticed a lack of rules given to a package creators hand. Then I checked my system for more issues, and found some. In the end, I started a discussion right here to get an idea if I am somehow corrupted by using debian such a long time - that is ruled to immobility - ore if this really are issues.
To point up why I won't write a bug report for things like missing desktop files:
· package maintainers have enough to do to fight real bugs while a desktop file is just touching the ease of use
· everyone can learn how to create a desktop file easily and therefore add his own
So why complaining at all, you may ask. I don't want to bother package maintainers with issues of less importand impact. I don't want them to change current packages, f.e. If they have time to spent on arch, I would be glad if they bash heavy bugs. But I would like to form a guideline for coming packages, as far as I am concerned as an arch user. I can't give an input for kde, enlightenment, fluxbox ore whatever environment, but as a gnome user.
During this thread, people mentioned we should wait untill a new wiki environment is available, and then work on a guideline set. I second that. When available, I would add my ideas for a guideline.
On the other hand, cactus was asking me if I could give him a list with issues I want to adress. I'll do my best, and have a deeper look into my system.
So, dusty, you should not blame me to just talk and do little.
Let's meet at the ok choral, 12'o clock. ![]()
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Let's meet at the ok choral, 12'o clock.
Noon or midnight? 8)
Offline
Dusty, he'd be in favour of the old "Arch Packaging Standards" doc then? :!:
Offline
which old?
Offline
sorry - colloquial english - "the old" as in "the"
Offline
oh... as in 'ye olde'.
Yeah, count him in on the packaging standard doc.
Dusty
Offline