kmod-mhvtl and mhvtl-utils packages available from ELRepo

[dagwieers]

Just to inform you we are adding mhvtl kernel module packages and the mhvtl helper package to ELRepo for RHEL5 and RHEL6 (and derivative distributions). You can find the SPEC files at:

• https://github.com/elrepo/packages/tree/master/mhvtl-kmod
• https://github.com/elrepo/packages/tree/master/mhvtl-utils

I will update this ticket as soon as we have them pushed to the testing repository.

[dagwieers]

There are a few items I would change with the current mhvtl tarball and RPM in order to accomodate packagers and users.

• Implement a proper make install so that packagers do not need to be on top of the changes in newer releases. This will prevent incorrect packaging as newly installed files and file locations will be maintained by the developers, and not the packagers.
• Please use the version for the tarball, and not a timestamp. Most of the packaging descriptions are designed to use versions, both for the package and for the tarball.
• Do not remove users and groups during uninstall. Typically data is not removed from the system during uninstall, and in this case the user and group removal will make those files 'unowned', if you would reinstall mhvtl the package will create a new user/group which may be different and another user may have access to these data files. General practice is to not remove users/groups as part of package removal. (Even better would be to have a static uid and gid)
• Use %{_libdir} so that /usr/lib and /usr/lib64 do not need different flows
• Put /opt/mhvtl inside of the package, it's not a good practice to create additional files and directories in post-install scripts as they become unowned.
• Add default runlevels in the sysv script, rather than use chkconfig mhvtl on
• I would remove the kmod-mhvtl.spec file from the tarball, since this one is very specific to RHEL5. Maybe it is better to leave the packaging up to the distributions/repositories instead.
• The changelog inside the SPEC file is used for changes to the SPEC file/package, not changes to the release. I know it is tempting to, but it is better to add a ChangeLog file instead that is shipped together with the package (for RPM using %doc)

[dagwieers]

Another consideration is to call the current mhvtl package mhvtl-utils like most other kernel modules package their additional userland tools. In some cases the -tools postfix is used, but most projects use -utils for this nowadays.

The advantage is that a '-utils' package makes clear there is something else required (rather than something self-sufficient).

[dagwieers]

RPM packages are now available from the RHEL5 and RHEL6 repositories at ELRepo. These packages are named kmod-mhvtl and mhvtl-utils. They work for RHEL, CentOS, Scientific Linux and Oracle Linux. We plan to keep them in sync with releases (provided there is a way to get updates).

More information is available from: http://elrepo.org/

[markh794]

On Thu, Jun 21, 2012 at 8:23 PM, Dag Wieërs [email protected] wrote:

Hi,

Just to inform you we are adding mhvtl kernel module packages and the mhvtl helper package to ELRepo for RHEL5 and RHEL6 (and derivative distributions). You can find the SPEC files at:

Sounds good.. Is there anything you would like from me ? Is there anything I can do to assist as newer improvements & bug fixes are applied ?

   https://github.com/elrepo/packages/tree/master/mhvtl    https://github.com/elrepo/packages/tree/master/mhvtl-kmod

Thanks for the pointers.. I should probably merge these into the main distribution.

I will update this ticket as soon as we have them pushed to the testing repository.

---

Reply to this email directly or view it on GitHub: https://github.com/markh794/mhvtl/issues/1

[dagwieers]

If there would be an announcement mailinglist, that would be nice. Or alternatively, if you could create a record of mhvtl on Freecode (fka freshmeat) and keep this updated with new releases, that helps me track and update my packages.

Also, I would appreciate it if you can mention the ELRepo packages on the mhvtl website, since most RHEL, CentOS, Scientific Linux and Oracle Linux people can benefit from these packages. (They are kernel agnostic, which means they survive a kernel upgrade).

[markh794]

On Wed, Jun 27, 2012 at 12:06 AM, Dag Wieërs [email protected] wrote:

If there would be an announcement mailinglist, that would be nice. Or alternatively, if you could create a record of mhvtl on Freecode (fka freshmeat) and keep this updated with new releases, that helps me track and update my packages.

I have just setup and submitted a request for 'mhvtl' package on Freecode.

Thanks for the pointer.

Also, I would appreciate it if you can mention the ELRepo packages on the mhvtl website, since most RHEL, CentOS, Scientific Linux and Oracle Linux people can benefit from these packages. (They are kernel agnostic, which means they survive a kernel upgrade).

---

Reply to this email directly or view it on GitHub: https://github.com/markh794/mhvtl/issues/1#issuecomment-6576429

[markh794]

Sorry, I didn't realize the suggestions you added here.

Can I have some examples of a "proper make install" as per your comment ?

"Implement a proper make install so that packagers do not need to be on top of the changes in newer releases. This will prevent incorrect packaging as newly installed files and file locations will be maintained by the developers, and not the packagers."

p.s. I'm starting to go through that list of bullet items and making corrections as appropriate.

Many thanks Mark

[dagwieers]

Well, at the moment my RPM packages contains a SPEC file (mhvtl-utils.spec) with a recipe of what I need to move from the build directory into the system. You can find the file here:

• https://github.com/elrepo/packages/blob/master/mhvtl-utils/el5/mhvtl-utils.spec

The %install section is prone to failure (or silent continuing) e.g. if you would add files that the section would not pick up. That is why we recommend upstream to provide a make install target with the required actions using a $(DESTDIR) variable that can be customized for packaging, so that we only have to add:

%install
%{__rm} -rf %{buildroot}
%{_make} install DESTDIR="%{buildroot}"

and upstream is in fact maintaining the procedure to install the software. Of course this would exclude the kernel module itself, which is specific per distribution and better left up to the packager.

[dagwieers]

I updated the packages to 1.4-4 at ELRepo. A few more suggestions ;-)

• Can we have a single version for the release and the package ? Currently the release is versioned 1.4-4, but the tarball contains mhvtl-1.4. The tarball name is 2012-09-13. This makes everything overly complex. Because RPM versions cannot contain dashes, I have to translate it into 1.4.4 instead. (The release number of a package is part of the packaging)
• Is it possible to make announcements on freecode.com so others (including me) can track new releases ?

Thanks !

[dagwieers]

The changes to the ELRepo packages are available from:

• https://github.com/elrepo/packages/commit/91a4bd59be19518aee9b2288535a22dbca28ba28
• https://github.com/elrepo/packages/commit/c473a72030d50bb34942224ba0bfeab0c0d23b8f

The sources are available here:

• https://github.com/elrepo/packages/tree/master/mhvtl-kmod
• https://github.com/elrepo/packages/tree/master/mhvtl-utils

The packages are available from:

• http://elrepo.org/linux/elrepo/ (Stable releases)
• http://elrepo.org/linux/testing/ (Test releases queued for stable repo)