[Bug 219687] [NEW PORT] net/google-compute-engine: User daemon for Google Compute Engine

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219687

--- Comment #9 from Helen Koike <helen.koike at collabora.com> ---
(In reply to Richard Gallamore from comment #7)

>> But now it uses version 20170609 instead of 2.4.0, is this ok? I feel that 2.4.0 should be somewhere as it is the version used in setup.py, what do you think?
>> I tried to use GH_TAGNAME=20170609 with PORTVERSION=2.4.0 but it doesn't seem to work the way I imagined
> Yes, revert back to how it was previously. This was a better solution, just
> needed to verify.
> 
>> With these changes now portlint returns:
>> # portlint -AC
>> looks fine.
> This is great.

The problem to revert it back I get:
# portlint -AC
FATAL: Makefile: either PORTVERSION or DISTVERSION must be specified, not both.

What is the best way to handle this?

> Couple things with the poudriere log.
> - Only the port listed in summary is required, in this case
> net/google-compute-engine.
> - Not sure how the build was invoked, but I usually use poudriere bulk -tC.(-t
> is for extra testing and -C will clean the specified package before build)
> I also want to note that poudriere bulk is not the recommended procedure. From
> the porters handbook, testport is suggested method, details here[1].

Thanks, I'll regenerate the poudriere tests like you suggested.

> 
> 
> When I initially went to the github repo, for some odd reason the README.md did
> not show up and was just blank with no information. Going back to it now, the
> information I was expecting is shown, so this work perfectly for WWW. There are
> some other items that need to be will need to be looked at.
> 
> - Portname. Usually this is the same as project name, but I don't think that
> would be a good fit. google-compute-image would be a bit more accurate, but
> more opinions would be best.

The github project is called compute-image-packages but it provides 3 different
packages as described at
https://github.com/GoogleCloudPlatform/compute-image-packages#packaging.
        - google-compute-engine
        - google-compute-engine-init
        - google-config
So I believe that we should have one port for each of them.
google-compute-engine-init is not necessary, as it only provides init scripts
but I already added rc scripts as .in files in the google-compute-engine
package.
google-config provide some udev rules, syslog configuration and bash scripts
for hostname and dhcp that are not really required for google-compute-engine
but I intend to port google-config latter.

So as there are 3 packages under the github compute-image-packages project, I
am porting just the google-compute-engine one, so I think it should keep this
name.

> - The comment should match the project comment on github minus "Linux".
> Changing this however with the current portname is a violation of having the
> portname in comment so waiting for portname feedback before deciding the
> correct comment.

Do you mean "Guest Environment for Google Compute Engine" ?
It could be, I am just wondering which should be the Comment in the future
google-config package

> - pkg-message.in[2]. Can you please provide a simple setup guide. It doesn't
> need to be long, just a simple how-to startup guide of procedures required
> after installing the package for the first time. If configuration is required,
> pointing to a url with more information would be great.

The easier configuration is a reboot to make the init scripts to start, I'll
write this in pkg-message and I can add a manual guide.

> 
> One more bit of information, how was the port tested? or is the port currently
> being used in production?

I am testing it by hand in a virtual machine running at Google Cloud Engine
platform.
The available tests in the upstream project are just mock tests that verifies
if the software calls the right functions in the right order, it doesn't really
check if it works or not and it can be biased as it was derivated directly from
the code. To enable the tests I'll also need to port each test, increasing the
number of patches and the maintenance complexity.
As I believe the mock tests are more important to the developer then to FreeBSD
(as it is implemented in the project), I don't think we need to bother to port
them. What do you think?


---
(In reply to Kubilay Kocak from comment #8)

Thank you Kubilay for reviewing this, I am updating the package with the
suggested changes and I'll attach it soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.