»Command-line Utilities« vs. »Packaging« categories
I have written two patches today which already existed. One, because I misunderstood something, the other because I searched for a bug in (and added my patch to) »packaging«, while the solution was in »Command-line Utilities«. Apart from having learned to take sunday off instead of writing redundant code, I wonder why we have these two categories which seem to be confusing to everyone. Take a look and you will see what I mean, there is a lot of koha-* scripts in both. Can we agree on having all command-line stuff used exclusively with package installations in »packaging« in the future? Cheers, Mirko PS. As it is redundancy day for me, I bet I have also missed an email saying exactly the same a few days ago. -- Mirko Tietgen mirko@abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de
Mirko Tietgen schreef op zo 28-06-2015 om 20:52 [+0100]:
Apart from having learned to take sunday off instead of writing redundant code, I wonder why we have these two categories which seem to be confusing to everyone. Take a look and you will see what I mean, there is a lot of koha-* scripts in both.
I actually got myself added to the CC of the command-line scripts category the other week because I noticed that was happening.
Can we agree on having all command-line stuff used exclusively with package installations in »packaging« in the future?
I'd be inclined to go the other way: if it's a command-line program at all, put it in the command-line category. My rationale behind this is that people who aren't regular committers shouldn't have to know what distinguishes a command line script from a package script. I also could argue that the scripts aren't really part of the packaging, but the boundary is hazy. But to be honest, I don't mind too much, though would like something to be chosen for exactly this reason (and, if there's a standard, then they can get triaged to the appropriate category easily enough if they're wrong.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Robin Sheat schrieb:
I'd be inclined to go the other way: if it's a command-line program at all, put it in the command-line category.
Works for me. I chose the other way mainly because it appeared to be the way you do it. The packaging manager should know, right? :) I'm happy with either option, as long as it is done consistently. Cheers, Mirko
I would like the Firefox OS email client to fail consistently, too, but it only mangled one set of »« in the subject. ;)
2015-06-28 16:52 GMT-03:00 Mirko Tietgen <mirko@abunchofthings.net>:
I have written two patches today which already existed. One, because I misunderstood something, the other because I searched for a bug in (and added my patch to) »packaging«, while the solution was in »Command-line Utilities«.
Apart from having learned to take sunday off instead of writing redundant code, I wonder why we have these two categories which seem to be confusing to everyone. Take a look and you will see what I mean, there is a lot of koha-* scripts in both.
Can we agree on having all command-line stuff used exclusively with package installations in »packaging« in the future?
I agree, those are command-line scripts, that happen to be shipped with the packages for now, but separation should be done to aid reporting. -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
First, I'm a huge proponent of having a single place to look for command line scripts... honestly, I wasn't aware of scripts outside of ./debian/command_line/, and I'm someone who actively looks for command line scripts. Would it be possible to make the scripts less dependent on being packaged? My impression is that a lot of the reasons for the dependency is hard coded paths, which probably aren't a good idea anyway... most of the scripts explicitly run under bash, which allows setting default values of shell variables, so it should be straightforward to set defaults which would allow the scripts to be extended to allow other paths while still being drop-in replacements for existing scripts. On Jun 29, 2015 7:54 AM, "Tomas Cohen Arazi" <tomascohen@gmail.com> wrote:
2015-06-28 16:52 GMT-03:00 Mirko Tietgen <mirko@abunchofthings.net>:
I have written two patches today which already existed. One, because I misunderstood something, the other because I searched for a bug in (and added my patch to) »packaging«, while the solution was in »Command-line Utilities«.
Apart from having learned to take sunday off instead of writing redundant code, I wonder why we have these two categories which seem to be confusing to everyone. Take a look and you will see what I mean, there is a lot of koha-* scripts in both.
Can we agree on having all command-line stuff used exclusively with package installations in »packaging« in the future?
I agree, those are command-line scripts, that happen to be shipped with the packages for now, but separation should be done to aid reporting.
-- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Barton Chittenden schreef op di 30-06-2015 om 16:56 [-0400]:
First, I'm a huge proponent of having a single place to look for command line scripts... honestly, I wasn't aware of scripts outside of ./debian/command_line/, and I'm someone who actively looks for command line scripts.
On a package install, that's pretty much all there is. There are others that a non-package install might use, but ideally they should all be wrapped by koha-* scripts in the packages.
Would it be possible to make the scripts less dependent on being packaged? My impression is that a lot of the reasons for the dependency is hard coded paths, which probably aren't a good idea anyway... most of the scripts explicitly run under bash, which allows setting default values of shell variables, so it should be straightforward to set defaults which would allow the scripts to be extended to allow other paths while still being drop-in replacements for existing scripts.
The package scripts are designed to expect a specific layout of Koha and Koha configuration. They're also designed to create things according to this layout, because that's what makes sense in a Debian environment. Other distributions have a different layout, and if you do a git install, anything could be anywhere, and there's not really an easy way to have scripts that know about that. So essentially my point is that the koha-* scripts in Debian are tied to the packaging because they work with a layout that is dictated by that. Separating them from that isn't really meaningful as they don't make sense if constraints are removed. This said, I am planning to remove the packaging from the Koha repo one day in the future so it can be maintained separately (this'll bring Koha more in line with how Perl packages are worked with in Debian.) I'm still in two minds as to whether the scripts and templates will come along when that happens or not. Probably not. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
participants (4)
-
Barton Chittenden -
Mirko Tietgen -
Robin Sheat -
Tomas Cohen Arazi