I am creating a jRuby gem at the moment and I may need to expose different commands (from the bin folder) to different type of users. Is that a good standard to create different gems for that, such as "_userX" or "_userY"? (And also the gem name may be different from the project name, which I know it's not a standard)
So I my need something like "mygem_for_admin_users" vs. "mygem_for_normal_users".
Cheers
It definitely works, and there are definitely people doing it (example: https://github.com/mongodb/mongo-ruby-driver).
This is obviously very subjective, but I personally feel that it's bad practice to have a gemspec that doesn't match the project name, or multiple gemspecs in a single project. Ultimately, if it's the cleanest solution to the problem, it's the cleanest solution, and you should go for it, but first consider other ways of going about it:
You could have one base gem and 2+ interface gems that expose different sets of commands from the base gem.
You could somehow identify the different classes of users from the library itself, making all the commands available, but some of them restricted unless the right user type is set
You could build everything into one command with many subcommands (like bundle or git) that does the same reasoning about user types
There may be more options.
TL;DR: It's not great practice, but people do it and nothing will catch on fire. Just make sure that there isn't an easy way to avoid it first.
Related
Let's say, I want to add a code-autogenerator for my gem/library. A code generator won't be a single executive cli file, but it'll contain source code as well as a cli file, and I'll be working on it too along with the main gem. Besides, it'll be written in a different language. I could move it into a different repository, but for now I've chosen to use a single repository. According to the convention, in what sub-directory in the main repository should I create that sub-project? opt, var, extra, tools....?
There is more likely no convention for a such situation and I think you already know the actually good solution: use a separate repository.
If this solution is not acceptable for now, a good option would be to put it in the folder with a name explaining its purpose. E.g. if it's a code generator, it could be inside "code_generator" or "tools/code_generator".
The Gentoo's ebuild mecanism comes with several built-in eclasses/commands to manage (amongst others) libraries, binaries, executables, etc... Some of them are really useful to work at installation phase, like setting permissions, modifying the default installation directory, etc...
About library installation, the ebuild documentation says :
dolib [list of more libraries]
Installs a library or a list of libraries into DESTTREE/lib. Creates all necessary dirs.
libopts [options for install(1)]
Can be used to define options for the install function used in the dolib functions. The default is -m0644.
The same is available for "executables": exeopts works with doexe.
Question
The thing I really don't understand is that why dobin and dosbin exist but not binopts and sbinopts?
Is it possible have libopts or exeopts equivalents for dobin and dosbin, to manage permissions at installation phase?
Because dobin and dosbin are special cases of doexe, which have pre-defined options; if you need special permissions (e.g. suid) you can use doexe as needed.
Effectively (/usr)/bin and (/usr)/sbin should be executable to all users, unless something special (like limiting access to a group that has access to the hardware) is needed.
(I would probably be in favour of removing libopts too, but that's a different story, I guess.)
I am making my own personal package to have collection of usefull programs and configs. Main idea is to emerge this package and have system prepared for my prefferencies. Mainly it works (it simply depends on all my favourite programs), but I have two problems here:
how to install USE flags, UNMASK and such before affected programs are installed?
how to uninstall it (emerge --unmerge does NOT delete files in /etc, so even after uninstalling the package the USE flags (and others) are still kept - my intent is to REMOVE them, so next rebuild of world would NOT use them anymore - yes it means a lot of programs would lose some functionalities like support for some languages, support for some other programs and so on, it is desired result)
My solutions so far are:
The package have some files in /etc/portage/package.*
1.1. I emerge that package with --nodeps (so the config files are installed)
1.2. I emerge it again without that flag (so dependencies are installed
with right configuration))
I create (and install) script to parse /var/db/packages for my package CONTENTS and delete all /etc/portage/something files "manually" and I have to rum this script before unmerging the package
Is there better way to do it ?
You just doing/understanding it wrong! (sorry :)
First of all, instead of a metapackage (an empty ebuild that have only runtime dependencies) there is other ways:
use sets to describe your preferred packages. Manage your USE flags in a usual way (including per package USE if needed).
medium complexity solution is to write a metapackage ebuild (your current case) -- but, you can't mask/unmask USE flags anyway…
if you already have your overlay (obviously) -- defining your own profile would solve everything! Here you can manage everything just like you want: mask/unmask any USE flags, define what is system predefined package means for you, & etc…
Unfortunately, I don't use Gentoo portage (and emerge) and have no idea if it's possible to have multiple additive profiles. I have my own profiles here and it works perfectly with Paludis.
Second, never remove any configuration files (config-protected) after uninstall! There is no packages that do that, and there is a bunch of reasons for that… The main one is that user may have them modified and don't want to loose his changes. Moreover, personally I prefer to have all configs that I've ever touched to be in a dedicated VCS repo -- it wouldn't be nice, if someone, except me, would remove smth…
Imagine a real life example: user wants to reinstall some package and he has a bunch of configuration files, he spent some time to carefully edit them. Trivial way is to uninstall and then install again -- Oops! He lost his configs!
Moreover, from ebuild's POV, you have pkg_prerm and pkg_postrm functions, but both of them are called even at upgrade time (i.e. when unmerge followed by immediate merge phase). You have to be really careful to distinct that use cases… And what is more scare, having any "hardcoded" (and unique) rules in any package, you don't have any influence on them…
So, please, never remove any config protected files, let the user to take care of them (he is the boss, not a package manager)…
Update: If you really want to be able to remove some config-protected files, setting up your own profile looks even more better idea. You can set CONFIG_PROTECT_MASK to enforce unprotect files and/or directories. In that way you don't need to modify any ebuilds and/or write an ugly cleanup code.
I have many bundles (let's say hundreds) and it is quite difficult to specify relation between bundles+features-distrubutions in UI. Image, at first I define all relations between bundles, features and distribution. Than I want to update some bundles... it is almost impossible to find them in current implementation of UI. They are not groupped and one list of all bundles without any search bar is really hard to work with.
Is there any support for a file based solution. For example Apache ACE would watch a certain folder containing distribnution's bundles. When ever I make a change there, it would be propagate it to all targets.
There is currently no file based solution that matches what you describe, however, I think there are still a couple of solutions that might help you:
There are two types of associations between artifacts and features in ACE: static and dynamic ones. The latter can be of help to you, as they always automatically bind to the highest version of a bundle. So, once you've made all your associations, you can simply upload a set of newer bundles and the associations will adapt.
There is also a REST API you can use to programmatically talk to ACE. You can use that to further automate your process.
That said, you have a valid point that it is difficult to keep an overview when there are a lot of artifacts in the first column. I would advise you to watch, or even contribute to the following issues that were all created to improve this situation:
https://issues.apache.org/jira/browse/ACE-319
https://issues.apache.org/jira/browse/ACE-320
https://issues.apache.org/jira/browse/ACE-321
I am trying to make a live CD for simplifying chrooting into unbootable Linux systems for users, as many unbootable Linux issues could be fixed with chroot, but many users probably don't understand the concept of chroot.
One of the abilities I want to add is the ability to temporarily import some utilities from the Live CD into the target system, so that they can be used as if they where installed, to do configuration tasks.
The problem is is that I can't seem to work around the apps trying to search for stuff in /usr/share when they are imported. (I already have a hacky workaround for /usr/lib using patchelf...) I would do a union mount on the /usr/share's, but that could confuse some package managers when they see files that should not be there, as the user might need to run a package manager to fix the broken system. (or at least I think it could confuse package managers).
I'm trying to see if I can create a script that will rebuild all packages to use a different build prefix instead of /usr. The script can rebuild packages with apt-get build-dep/apt-get source/debbuild, but it can't change the prefix.
Question: Is there a way to pass an argument to debuild or dpkg-buildpackage to change the build prefix?
Right now it seems I have to take a look at the contents of the source (from apt-get source) for every package and see what files are specifying /usr and figure out a way to change it for every one, but I have a feeling I'm missing something obvious...
Is this possible?
I don't think this is feasible. Why don't you mount in a different location, for example /usr/local? That way, you also eliminate a source for possible conflicts.
Still, some packages are full of hardcoded references to the location for their data files, for example.
I'll throw in a pointer to stow as well, although I imagine it's not really helpful for your scenario.