| View previous topic :: View next topic |
| Author |
Message |
adrelanos
n00b
Joined: 11 Dec 2014
Posts: 6
|
 Posted: Sun Dec 21, 2014 5:32 pm Post subject: ebuild takeover ownership of other packages (config) files? |
 |
|
Is there a way or tool to take over ownership of (configuration or other) files owned by other Gentoo packages? So the config package won't conflict with updates by the original package?
Does Gentoo have something similar to config-package-dev?
config-package-dev is a Debian specific tool that allows to easily create configuration packages, that may modify configuration files owned by other packages in a clean and robust way. (Which is internally using among other things: dpkg-divert.)
I.e. in Gentoo terms, one (such as a Gentoo derivative) could create an ebuild, that for example ships a tor-config package, that ships its own /etc/tor/torrc config file without conflicting with the original Gentoo tor package.
Background:
We are planning to port Whonix (github) - which is currently based on Debian - to Hardened Gentoo. Whonix consists of a lot packages ([list]). Some of them ship configuration files. Due to the nature of the project, some of them modify configuration files owned by other (Gentoo / Debian) packages.
_________________
... |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Dec 21, 2014 6:53 pm Post subject: |
|
|
adrelanos ...
without asking further questions, and so gain some insight into how you plan on creating this "port", it seems as though you may be going about this the wrong way. If there is a package from the gentoo repo you need to modify then this package should be supplied by your overlay (and so replace the gentoo package).
So, the gwhonix repo consists of those packages being modified (even if only supplying a config) you then have <category>/<package>::gentoo in package.mask and so the overlay package will be used in its place.
This way its simple for others to add the overlay, edit package.mask, and emerge <package>, @world, or @set and require the configuration (or patches, etc) you intend. Once the configuration is installed the user runs 'dispatch-conf' or 'etc-update' and merges in your changes with their current working config (or simply replaces it with the ::gwhonix supplied config).
HTH & best ... khay |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Sun Dec 21, 2014 8:00 pm Post subject: |
|
|
adrelanos,
There are a lot of Gentoo derivative distros out there already. They are mostly Gentoo plus their own overlay which works as khayyam describes.
Have a look as some of the derivatives.
Good luck with your port of Whonix.
--- edit ---
Its quite common for devs and advanced users to run their own local overlay anyway.
Dip a toe in the water, install hardened Gentoo following the handbook. Write a set called whonix, so emerge @whonix will install whonix on top of basic Gentoo.
Where you need to choge things to get what you want, create an overlay called whonix and put your modified ebuids and patches there.
For practice, write a set called debian, so you can do emerge @debian :)
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
adrelanos
n00b
Joined: 11 Dec 2014
Posts: 6
|
| Posted: Thu Jan 01, 2015 8:40 am Post subject: |
|
|
| khayyam wrote: | without asking further questions, and so gain some insight into how you plan on creating this "port", it seems as though you may be going about this the wrong way. If there is a package from the gentoo repo you need to modify then this package should be supplied by your overlay (and so replace the gentoo package).
|
For such simple config changes, I'd prefer to avoid forking / maintaining the whole package original package. Usually package maintainers are doing an awesome job and updating an update each time the gentoo maintainer pushes and update would add a lot overhead just for the config file change.
_________________
... |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Thu Jan 01, 2015 10:00 am Post subject: |
|
|
| Aren't you just looking for epatch? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Thu Jan 01, 2015 11:31 am Post subject: |
|
|
adrelanos,
Its not really a fork. You maintain your own patch set which you migrate from package version to package version.
In many cases, its just renaming your ebuild file to be the new version and generating the digest.
krinns epatch (epatch_user) suggestion mostly works too. The down side is that not all packages support epatch_user, so you will be back to the above anyway, even if its just to add epatch_user to the ebuild, so you can use it. epatch_user cannot patch the ebuild itself as its called by the ebuild.
The advantage of your own overlay is that its easy to distribute. It can be in the version control system of your choice and your users install it with layman.
If you don't wan't to distribute anything, it doen't much matter. The overlay only contains ebuilds and pactes that you want to change, not everything
You need to get your feet wet with Gentoo and see how it works. Gentoo is very difficult to fork, as its really only the Portage package manager and the ebuilds.
All of the derivatives except one, use the overlay approach. The odd one is Exherbo, who really are forking as they don't use the ebuilds at all.
You want to use the tools that Gentoo provides to make your own distro. Thats fine, you are following a well trodden path.
Even I'm trying with the gentoo-static overlay - but git keeps frighenenig me away.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Jan 01, 2015 12:11 pm Post subject: |
|
|
| NeddySeagoon wrote: | You want to use the tools that Gentoo provides to make your own distro. That's fine, you are following a well trodden path.
Even I'm trying with the gentoo-static overlay - but git keeps frightening me away. |
#git are your friends ;)
Here's my setup which should give you some ideas for the most common operations for someone who doesn't really get git, but just needs to use it.
Mostly I use add -p somefile, followed by staged to see what I'm committing and review in context with vstaged somefile, repeat a couple of times if there's more bits to the change, then a commit.
Without aliases, those are: git add -p somefile followed by git diff --staged and in context with git difftool -y --staged somefile, and naturally git commit which I usually run in one terminal window, while reviewing the staged diff in another, so the commit message is easier to write.
That accounts for I reckon 90% of my usage; the other times I usually check with #git first, before proceeding, normally after having got lost in manpages. ;)
git push happens quite infrequently by comparison to adds and commits, at least for code or scripted applications.
I don't alias it because I want to be sure I'm ready, before I push. I tend to run gitview --all first, for a different perspective (aka: view.) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Jan 01, 2015 4:38 pm Post subject: |
|
|
| adrelanos wrote: | | khayyam wrote: | without asking further questions, and so gain some insight into how you plan on creating this "port", it seems as though you may be going about this the wrong way. If there is a package from the gentoo repo you need to modify then this package should be supplied by your overlay (and so replace the gentoo package).
|
For such simple config changes, I'd prefer to avoid forking / maintaining the whole package original package. Usually package maintainers are doing an awesome job and updating an update each time the gentoo maintainer pushes and update would add a lot overhead just for the config file change. |
adrelanos ... no, not really. In fact if you are propagating those changes then an overlay is the correct way to manage it. A config file is part of a package, managed by the package manager, and changes are propagated by <category/package>::repo, so when <category/package>::gentoo is bumped the config is marked as needing merged (dispatch-conf'd or etc-update'd). If gwhonix is providing a specific configuration then these should be tied to the package (and so easily merged) otherwise conf.d/<package>, and/or /etc/*, will be available for merging when <category/package>::gentoo is updated. That may not sound as straightforward as the debian method, but packages on gentoo don't modify config files ... they simply provide them.
Now, the maintenance involved isn't the same as forking, its simply a matter of tracking the packages involved and bumping them when they are updated, this is often no more than moving one file from one place to another.
best ... khay |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
