From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Few questions concerning creating addon package Date: Mon, 29 Mar 2021 08:31:22 +0200 Message-ID: <2a2a775c-9347-2d41-2b82-1be76840bbc1@ipfire.org> In-Reply-To: <70dabbe4d5fee26d2fded33e9b150e9050fda7d6.camel@disroot.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7319082018774994286==" List-Id: --===============7319082018774994286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Robin, On 28/03/2021 23:41, Robin Roevens wrote: > Hi Adolf >=20 > Thanks for the feedback. Glad to help. >=20 > Adolf Belka schreef op zo 28-03-2021 om 22:21 [+0200]: >> >>> So I'm assuming ${NAME} is not available when I manually run >>> install.sh >>> as per instructions, and that it will be available when pakfire >>> itself >>> installs the package? >> That is correct in both cases. >>> Is there a way to test the actual package deployment using pakfire >>> ? >> >> When I am testing a package what I do is run the following commands >> first:- >> >> NAME=3D"zabbix_agentd" >> >> export NAME >> >> That then sets $NAME to your package name and should make all >> commands that use $NAME work successfully. >> >> Hopefully that will also help you. >> > Ok, that should indeed do the trick then. I added it to the testing > example in the wiki page, so that is clear for future package > maintainers following those instructions. Excellent. >=20 >>> Then I have a few other questions: >>> - In the LFS template there is a PAK_VER variable, and it is not >>> clear >>> to me what this exactly is. Is this a revision number for current >>> packaged version?=C2=A0or just a 'counter' for how many package versions >>> there have been for this program in IPFire ? >> In IPFire 2.x it is used as a continuously incrementing counter so >> you should set it one higher than the previous version. It never >> resets. (That is different to what the aim is for IPFire 3 but that >> is still under development). >=20 > Thanks for the clarification. The wiki page didn't mention PAK_VER, so > I also added that to the page. >=20 >>> - In the LFS template for current zabbix_agentd v4.2.6 DL_FROM is >>> pointing to URL_IPFIRE.. Should this be changed ? Or should I >>> upload >>> the new source-file for v5.0.9 to URL_IPFIRE in some way ? (are >>> there >>> instructions somewhere?) or ..? >> Leave that as it is and when you run ./make.sh downloadsrc if it >> completes successfully then it means that the new version you are >> using was successfully downloaded by the IPFire source system. IPFire >> keeps a copy on their system of all source tarballs in case the >> original versions have a problem. >=20 > Ok. But then how will the IPFire source system know from where to > download the original source tarball to keep as a copy ? Do I have to > request the file to be added to URL_IPFIRE supplying the source url on > this mailing list, or in the patch comments? Or do I put the copy of > the source there myself some way ? As I understand it:- The first time a new addon is submitted then the URL_IPFIRE is replaced with = the url for the tarball source location. After that then the IPFIre system basically uses the same source location to = look for the new version number you provide. There is only a problem if the url for the source location is changed. >=20 >>> Then a more practical question: >>> Next to 'just' an upgrade of the current Zabbix agent I also added >>> a >>> few config files etc for use with my Zabbix IPFire specific >>> monitoring >>> template. This changes Alexander's original config a little, but >>> should >>> remain backwards compatible. >>> Should I submit this as 2 separate patches or will a single patch >>> suffice? >> >> I think the core devs prefer changes separated but it depends, they >> would be best to comment on that. >> >> I think it depends on how closely integrated the changes are. You can >> do them as a single patch, you can do them as a series of patches >> [PATCH 1/2] and [PATCH 2/2] or as completely separate patches. To me >> it sounds like probably a series would make sense. >> >> For a series do a git commit -s on the changed files that make up >> your core change and then do a second git commit -s on the additional >> changed files. Then do a git format-patch -o ..... command and it >> will create two patch files 0001.... and 0002.... from the two >> commits. Hopefully that is clear enough. >> > Alright, I will try a series then. With the first just an upgrade, > keeping the customization of Alexander intact, and next one 'upgrading' > those customizations for compatibility with my own Zabbix monitoring > template (currently available on my github and on share.zabbix.com). >=20 >> I would also say that if you make your best effort with your >> submission you will get feedback on if you should have done it >> differently but it will be friendly constructive feedback. I have had >> that sort of feedback myself and it has always been an opportunity to >> learn and do better the following time. > Looking forward to it :-) >=20 >> >> I look forwards to seeing your update successfully getting into Core >> Update 156. > I'll do my best releasing my patch serie in the next few days.. >=20 > And if I understand correctly, as you can currently select in the webUI > which 'branch' pakfire should use as source, I will be able to install > my version of the package from the "Unstable" branch on a stable IPFire > instance as soon as my patches are approved and committed ? Yes that is true. However it is named unstable and things do break occasional= ly. >=20 > Thanks! >=20 > Regards > Robin >=20 >=20 --===============7319082018774994286==--