| Summary: | sys-fs/trustees removal notice | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | matts |
| Component: | New packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | max, robbat2, treecleaner |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Ebuild for Linux Trustees 3.0
Extra Gentoo-related files for Linux Trustees 3.0 Updated ebuild Descriptive example configuration file conf.d file for Trustees service Trustees service init script Updated ebuild Updated ebuild for trustees-3.0 |
||
|
Description
matts
2005-09-13 20:04:46 UTC
Created attachment 68422 [details]
Ebuild for Linux Trustees 3.0
The gentoo-extra tarball requested by this ebuild (which includes the Gentoo
initscript and conf.d file) is in another attachment to the bug.
Created attachment 68423 [details]
Extra Gentoo-related files for Linux Trustees 3.0
Please resubmit the ebuild with the standard Gentoo header at the top, for copyright purposes. Created attachment 88129 [details]
Updated ebuild
I've copied the standard copyright header into the ebuild.
that prerm block is still questionable. if the package is upgraded, it would run, and stop trustees on your system. That's something I hadn't thought of when I wrote this. So for ebuilds which install new services, is the standard to let the user figure out on their own that they need to stop the service before uninstalling? Or is there an easy and reliable way to see if we are being upgrading vs. removed? yup, usually user responsibility. no easy way to check upgrade vs. removal. There's a few seemingly trivial routes, but they are frought with non-trivial complications. btw, you should also attach the contents of that tarball as several individual files here - there are some developers that (rightly so), won't touch tarballs/gzip/bzip stuff from untrusted source, given the past existence of gzip security holes. Created attachment 102416 [details]
Descriptive example configuration file
An example configuration file with descriptive comments.
Created attachment 102417 [details]
conf.d file for Trustees service
The /etc/conf.d config file for the Trustees service.
Created attachment 102418 [details]
Trustees service init script
Trustees service init script.
Created attachment 102421 [details]
Updated ebuild
OK, the new ebuild has no more prerm stuff, and refers to individual config files in ${FILESDIR}, which should be /usr/portage/sys-apps/trustees/files. That seems to be the usual place to put init.d and conf.d files.
Created attachment 102422 [details]
Updated ebuild for trustees-3.0
Whoops, I forgot to remove the gentoo-extras tar file from the src list.
(In reply to comment #12) > Created an attachment (id=102422) [edit] > Updated ebuild for trustees-3.0 > > Whoops, I forgot to remove the gentoo-extras tar file from the src list. > Perhaps this package should now be removed? "The reason for this rather large change in how trustees is developed is that for one thing, it makes life actually a bit simpler for me. Secondly, as of 2.6.24-rc1 (and the upcoming 2.6.24 kernel) the API's I'm using are no longer available for kernel modules. Trustees will *need* to be compiled statically." Yes, this should be removed now, as the package only works with older kernels. (In reply to comment #14) > Yes, this should be removed now, as the package only works with older kernels. > Okay, sorry we couldn't get it in the tree back when you were working on it! Thanks for the prompt response. removed from tree. |
