Hi, One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs. A couple of days ago I saw that the openbox port was moving a file because the maintainer thought it was misplaced, but it wasn't (see http://crux.nu/svnweb/CRUX/revision/?rev=1781) - since the maintainer happened to be tilman, the change was reverted 5 seconds after I told him it was bogus and 10 seconds before I requested a revert :) I've been using/packaging the dchroot utility from Debian for a while. It's a small setuid utility to allow regular users to chroot into a specified list of directories. Because the path of 'su' is hardcoded to /bin/su and CRUX keeps su in /usr/bin/su, I've only used it for Debian chroots (running on CRUX) so far. Now, the other day I accidently looked at the shadow Pkgfile, and to my surprise su is actually installed in /bin and then moved manually to /usr/bin. To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)
Mark Rosenstand [2006-09-08 10:44]: Hi,
One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs.
We _still_ do. But it's probably related to the fact that we don't read all of the code of the software we're packaging and that we don't fix any and all bug (-> Debian ;D).
I've been using/packaging the dchroot utility from Debian for a while. It's a small setuid utility to allow regular users to chroot into a specified list of directories. Because the path of 'su' is hardcoded to /bin/su and CRUX keeps su in /usr/bin/su, I've only used it for Debian chroots (running on CRUX) so far. Now, the other day I accidently looked at the shadow Pkgfile, and to my surprise su is actually installed in /bin and then moved manually to /usr/bin.
Per probably had a good reason to do this... Would be okay by me to undo that change though.
To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)
Uh uh, I actually thought twice before doing that Openbox commit. I even contact upstream, ziomg! ;) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 10:44]:
Hi,
One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs.
We _still_ do. But it's probably related to the fact that we don't read all of the code of the software we're packaging and that we don't fix any and all bug (-> Debian ;D).
Totally fair, and that's also why I argue that keeping close to (if not verbatim) upstream is the best bet for a project the size of CRUX. Personally I've had great success getting things such as DESTDIR fixes included upstream, making it a joy to maintain packages in the long run. Unfortunately I've had to fork some opt packages lately. For example, I depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it for something I have no clue what does (http://crux.nu/svnweb/CRUX/revision?rev=1701)
I've been using/packaging the dchroot utility from Debian for a while. It's a small setuid utility to allow regular users to chroot into a specified list of directories. Because the path of 'su' is hardcoded to /bin/su and CRUX keeps su in /usr/bin/su, I've only used it for Debian chroots (running on CRUX) so far. Now, the other day I accidently looked at the shadow Pkgfile, and to my surprise su is actually installed in /bin and then moved manually to /usr/bin.
Per probably had a good reason to do this... Would be okay by me to undo that change though.
Looking forward, it'd be nice if packagers would comment why they do such things in the Pkgfiles (unless it's obvious, say "mv $PKG/usr/share/man $PKG/usr/man") I think that recently there have been a growing number of patches in core and opt - are upstreams just getting insane? I get the feeling that the heavy patching is also the primary reason we're stucked with years old versions of things such as grub. I recently made an attempt to make udev less distro-specific (and hence more maintainable) but it seems that by now (6 revisions later) things are pretty much back to the pain it was before.
To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)
Uh uh, I actually thought twice before doing that Openbox commit. I even contact upstream, ziomg! ;)
Ah, true, you said that. I shouldn't have used that as an example, it was rather a case of "shit happens" :) The autoconf 2.60 mandir patch was probably a better example.
Hi, 2006/9/8, Mark Rosenstand <mark@borkware.net>:
I've been using/packaging the dchroot utility from Debian for a while. It's a small setuid utility to allow regular users to chroot into a specified list of directories. Because the path of 'su' is hardcoded to /bin/su and CRUX keeps su in /usr/bin/su, I've only used it for Debian chroots (running on CRUX) so far. Now, the other day I accidently looked at the shadow Pkgfile, and to my surprise su is actually installed in /bin and then moved manually to /usr/bin.
Per probably had a good reason to do this... Would be okay by me to undo that change though.
Looking forward, it'd be nice if packagers would comment why they do such things in the Pkgfiles (unless it's obvious, say "mv $PKG/usr/share/man $PKG/usr/man")
I am still a crux-newbee and take a look to the handbook quiet a lot. Installing most of a packages stuff under /usr is listed as one of the major guidelines in "http://crux.nu/Main/Handbook2-2#ntoc24". A comment on this specific topic should maybe be placed at this place. matthias
Mark Rosenstand [2006-09-08 11:53]:
On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 10:44]:
One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs.
We _still_ do. But it's probably related to the fact that we don't read all of the code of the software we're packaging and that we don't fix any and all bug (-> Debian ;D).
Totally fair, and that's also why I argue that keeping close to (if not verbatim) upstream is the best bet for a project the size of CRUX.
Sure, I think everyone agrees here.
Unfortunately I've had to fork some opt packages lately. For example, I depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it for something I have no clue what does (http://crux.nu/svnweb/CRUX/revision?rev=1701)
You could had asked Matt, Johannes, or me about it (it was kinda a group effort to get that bug nailed :) The patch has been incorporated into GTK+ 2.10.2, btw. See the changelog for the bug ID (it's tiny, I'm too lazy to look it up right now). I think it's safe to assume that your GTK maintainer depends largely on GTK+/Gnome, too... I think applying that patch was the right thing to do...
I think that recently there have been a growing number of patches in core and opt - are upstreams just getting insane? I get the feeling that the heavy patching is also the primary reason we're stucked with years old versions of things such as grub.
I don't share the feeling that core and opt are getting more patches recently. I'm not saying it's not true, I just didn't notice it. Regarding grub - the version we're using isn't actively developed anymore AFAIK. Switching to the new development branch seems a bit risky to me. I'd rather stick to the old version here.
To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)
Uh uh, I actually thought twice before doing that Openbox commit. I even contact upstream, ziomg! ;)
Ah, true, you said that. I shouldn't have used that as an example, it was rather a case of "shit happens" :)
The autoconf 2.60 mandir patch was probably a better example.
Agreed, that was a bit silly. We also already discussed that matter ;) I don't see how one case of "shit happens" and one case of sillyness shows a trend of messing up opt ;D Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 2006-09-08 at 12:25 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 11:53]:
On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 10:44]:
One of my personal likings of CRUX is that it's easy to customize and extend. Because it (used to?) keep as close to upstream as possible, there tend to be fewer distribution-specific bugs.
We _still_ do. But it's probably related to the fact that we don't read all of the code of the software we're packaging and that we don't fix any and all bug (-> Debian ;D).
Totally fair, and that's also why I argue that keeping close to (if not verbatim) upstream is the best bet for a project the size of CRUX.
Sure, I think everyone agrees here.
:)
Unfortunately I've had to fork some opt packages lately. For example, I depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it for something I have no clue what does (http://crux.nu/svnweb/CRUX/revision?rev=1701)
You could had asked Matt, Johannes, or me about it (it was kinda a group effort to get that bug nailed :) The patch has been incorporated into GTK+ 2.10.2, btw. See the changelog for the bug ID (it's tiny, I'm too lazy to look it up right now).
I think it's safe to assume that your GTK maintainer depends largely on GTK+/Gnome, too...
I think applying that patch was the right thing to do...
If it was a bug fix, sure! The problem is that there were no description of what it did, "added cptn's modified stock icon patch" doesn't tell much. The fact that it fixed a bug, and preferably what bug it fixed as well as it was applied upstream would have been really nice additions to that commit message. (This is a general problem, I think. Take http://crux.nu/svnweb/CRUX/revision/?rev=1678 for instance.)
I think that recently there have been a growing number of patches in core and opt - are upstreams just getting insane? I get the feeling that the heavy patching is also the primary reason we're stucked with years old versions of things such as grub.
I don't share the feeling that core and opt are getting more patches recently. I'm not saying it's not true, I just didn't notice it.
It could just be me being more sensitive to this :)
Regarding grub - the version we're using isn't actively developed anymore AFAIK. Switching to the new development branch seems a bit risky to me. I'd rather stick to the old version here.
I'm all for sticking to the widely used 0.x branch, but 0.95 is 2.5 years old and 0.97 have been available for more than a year. The patches applied to 0.95 include additions of essential features such as support for splash images, and there's so many that they're distributed in an out-of-tree tarball!
To avoid these kinds of distribution-specific problems, I'm kindly asking packagers to think twice before deciding to divert from upstream - perhaps even limiting it to "required for essential functioning of the package" and basic CRUX integration (no nls, man-pages in /usr/man, etc.) :)
Uh uh, I actually thought twice before doing that Openbox commit. I even contact upstream, ziomg! ;)
Ah, true, you said that. I shouldn't have used that as an example, it was rather a case of "shit happens" :)
The autoconf 2.60 mandir patch was probably a better example.
Agreed, that was a bit silly. We also already discussed that matter ;) I don't see how one case of "shit happens" and one case of sillyness shows a trend of messing up opt ;D
Those were just the ones on the top of my head, but I have to admit that I don't understand what all the shadow patches are for. Some comments in the patch headers or in the Pkgfile would be warmly welcomed - after all there's a lot of tinkerers in the CRUX crowd (cruwd? OK, no more coffee on my day off) :)
Mark Rosenstand [2006-09-08 12:59]:
On Fri, 2006-09-08 at 12:25 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 11:53]:
On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:
Mark Rosenstand [2006-09-08 10:44]:
Unfortunately I've had to fork some opt packages lately. For example, I depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it for something I have no clue what does (http://crux.nu/svnweb/CRUX/revision?rev=1701)
You could had asked Matt, Johannes, or me about it (it was kinda a group effort to get that bug nailed :) The patch has been incorporated into GTK+ 2.10.2, btw. See the changelog for the bug ID (it's tiny, I'm too lazy to look it up right now).
I think it's safe to assume that your GTK maintainer depends largely on GTK+/Gnome, too...
I think applying that patch was the right thing to do...
If it was a bug fix, sure! The problem is that there were no description of what it did, "added cptn's modified stock icon patch" doesn't tell much. The fact that it fixed a bug, and preferably what bug it fixed as well as it was applied upstream would have been really nice additions to that commit message. (This is a general problem, I think. Take http://crux.nu/svnweb/CRUX/revision/?rev=1678 for instance.)
Putting BTS IDs/references in commit comments and patch file names seems like a good idea.
Regarding grub - the version we're using isn't actively developed anymore AFAIK. Switching to the new development branch seems a bit risky to me. I'd rather stick to the old version here.
I'm all for sticking to the widely used 0.x branch, but 0.95 is 2.5 years old and 0.97 have been available for more than a year.
Okay, file a bug for this.
Uh uh, I actually thought twice before doing that Openbox commit. I even contact upstream, ziomg! ;)
Ah, true, you said that. I shouldn't have used that as an example, it was rather a case of "shit happens" :)
The autoconf 2.60 mandir patch was probably a better example.
Agreed, that was a bit silly. We also already discussed that matter ;) I don't see how one case of "shit happens" and one case of sillyness shows a trend of messing up opt ;D
Those were just the ones on the top of my head, but I have to admit that I don't understand what all the shadow patches are for. Some comments in the patch headers or in the Pkgfile would be warmly welcomed - after all there's a lot of tinkerers in the CRUX crowd (cruwd? OK, no more coffee
Okay. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
participants (3)
-
Mark Rosenstand -
Matthias Pfeifer -
Tilman Sauerbeck