Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Alan, thanks for the more detailed explanation. On Sun, Aug 29, 2010 at 05:38:06PM -0400, Alan O'Neill wrote: > Hi Andreas, > > To explain further about the directory permission thing, when I built > the Debian package, I started by running GT.M's 'config' script, > installing GT.M into the directory /usr/lib/fis-gtm/V5.4-000A_x86. I > answered the installation questions as follows: > > File owner: bin Because I was not sure about the system user bin myself I asked on debian-mentors list. I'm hereby quoting the answer[1]: HELP: No files on my system are owned by user or group bin. What good are they? Historically they were probably the owners of binaries in /bin? It is not mentioned in the FHS, Debian Policy, or the changelogs of base-passwd or base-files. LSB 1.3 lists bin as legacy, and says: "The 'bin' UID/GID is included for compatibility with legacy applications. New applications should no longer use the 'bin' UID/GID." The Debian Policy Manual also includes a statement about file permissions and owners in section 10.9: Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755. Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it. Following this advise I would recommend instead of using user bin just to create a new system user via adduser --system gtm (or some more reasonable user name) and use this one in the installation questions. > > Unicode support: yes > ICU version: 4.2 > Lower case versions of MUMPS routines: no > > The config script sets up the the following directories with 'r-xr-xr-x' > (i.e. not writable) permissions: > > - V5.4-000A_x86 > - V5.4-000A_x86/utf8 > - V5.4-000A_x86/plugin > - V5.4-000A_x86/plugin/gtmcrypt > - V5.4-000A_x86/plugin/gtmcrypt/utf8 > > Additionally, some of these directories contain symbolic links. If I > build the Debian package and maintain the non-writable permissions on > the directories, when someone wishes to extract the package (dpkg -x) > without root privileges, Do you have any practically relevant case in mind why someone without root privileges should wish to extract the content of the package manually? > they get errors because the directories do not > have write permission. So what I did was change the permissions on > these directories to rwxr-xr-x in the Debian package. When the actual > install occurs, the 'postinst' script does a chmod to put the > permissions on these directories back to r-xr-xr-x. I took this step > because Bhaskar had requested that the package be extractable without > root privileges. Bhaskar, could you please elaborate more detailed on this requirement? Perhaps there is another solution for this instead of playing around with permissions in an unusual way. > You mentioned that I should not rely on the user ID of any user. I was > concerned about that too, which is why I placed the two following > commands at the end of the postinst script: > > chown -R --from=0:2 root:$owner "$version" > chown -R --from=2:2 $owner:$owner "$version" > > On my system, the value of '2' is assigned to user bin and the value of > '0' is assigned to root. (I suspect root is always assigned the value > of zero, but just in case... :) This way, I ensure that the ownership > is correct, regardless of the value assigned by a particular system. If I'm not missleaded only the UID 0 has a special meaning and enables the user with this ID to superuser powers. *Usually* (but not necessarily) this user is called root. (IMHO, you can give this user any name, only the UID is checked - but that's an academical issue). To my knowledge no other UIDs are guaranteed to have any special meaning and as written above the use of user name bin is deprecated. > Regarding 'svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk' > and the GT.M scripts that I referenced, I wasn't trying to get into too > much detail about them right now. (I wouldn't mind doing it, but I > didn't want to muddy the waters.) I was just wondering whether everyone > was okay with the idea of using update-alternatives to link the Fidelity > supplied script of '/usr/lib/fis-gtm/V5.4-000A_x86/gtm' to the name > 'gtm-su' (instead of simply 'gtm'). I personally have no problem with gtm-su. It is just a name and if you regard it as useful it is fine for me. > My thought is that since the > Fidelity supplied script named 'gtm' uses a database that is in the > user's home directory, it's more similar to a single-user version of > GT.M (i.e., if the system is setup so different users cannot access each > others home directory, then effectively GT.M becomes single user
Re: ncbi-tools under Debian Med group maintenance?
u...@debian.org (Aaron M. Ucko) writes: > lately.) I now have a plausible-looking draft Git repository, but am > holding off on pushing it anywhere public until I get a chance to > sanity check it further. This review ended up falling by the wayside for far longer than I intended, for which I must apologize; however, a new upstream release (more on that below) prompted me to revisit it over the weekend. I've posted my final draft, complete with merge annotations and pristine-tar metadata, at git://amu.scripts.mit.edu/ncbi-tools6.git (browsable via http://amu.scripts.mit.edu/gitweb.cgi?p=ncbi-tools6.git;a=summary ) in case anyone wishes to review it further before I upload an official version to Alioth (probably within a week, but not for at least a day or two). To make a long story short, my caution in pushing my initial conversion attempt proved justified as I wound up having to redo it, in large part because I hadn't properly configured git-svn for the two-level branch layout I was using (svn-buildpackage's default, at least when storing all upstream sources per my preference). As for the new upstream release, I'm planning to upload it to experimental out of respect for the freeze; however, I'm tempted to ask the release team for a freeze exemption for a subsequent upload to unstable. (The previous release was a year ago, and the main impact will be on other binary packages from the same source; there are a few others that depend on libncbi-tools6 or libvibrant6a, but not on portions that change at all rapidly.) Any thoughts on the matter? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlzkw4j8cv.fsf...@dr-wily.mit.edu
Re: ncbi-tools under Debian Med group maintenance?
Hi Aaron, On Mon, Aug 30, 2010 at 01:52:48PM -0400, Aaron M. Ucko wrote: > > This review ended up falling by the wayside for far longer than I > intended, for which I must apologize; however, a new upstream release > (more on that below) prompted me to revisit it over the weekend. I've > posted my final draft, complete with merge annotations and pristine-tar > metadata, Sounds good. > at git://amu.scripts.mit.edu/ncbi-tools6.git (browsable via > http://amu.scripts.mit.edu/gitweb.cgi?p=ncbi-tools6.git;a=summary ) in > case anyone wishes to review it further before I upload an official > version to Alioth (probably within a week, but not for at least a day or > two). IMHO there is no need for an extra staging git repository outside Alioth. If you simply use UNRELEASED as "target distribution" every other member of the group knows that this packaging is unfinished and subject of change. > As for the new upstream release, I'm planning to upload it to > experimental out of respect for the freeze; however, I'm tempted to ask > the release team for a freeze exemption for a subsequent upload to > unstable. (The previous release was a year ago, and the main impact > will be on other binary packages from the same source; there are a few > others that depend on libncbi-tools6 or libvibrant6a, but not on > portions that change at all rapidly.) Any thoughts on the matter? My (quite uneducated about NCBI tools) opinion is that a more recent stable release than the more than a year old one would make perfectly sense. So asking for a freeze exceptions seems to make sense. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100830202050.gc23...@an3as.eu
Re: ncbi-tools under Debian Med group maintenance?
Andreas Tille writes: > Sounds good. Thanks! > IMHO there is no need for an extra staging git repository outside > Alioth. If you simply use UNRELEASED as "target distribution" every > other member of the group knows that this packaging is unfinished and > subject of change. I understand and appreciate that. However, I would still like to hold off on uploading to Alioth for the moment to reserve the right to correct any further problems that turn up with how I've represented the *existing* history. I think it's all essentially in order at this point, but that's what I said last time. ;-) > So asking for a freeze exceptions seems to make sense. Thanks for supporting the idea. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/udlsk1vkedz@dr-wily.mit.edu
