Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

Hi,

when I started snapping CUPS back in 2017, the CUPS source was still maintained 
at Apple and therefore I created the separate repo cups-snap at OpenPrinting.

As I generally recommend that Snaps should be created by the respective upstream 
projects I am snapping all the projects of OpenPrinting, including CUPS, and 
also the (retro-fitting) Printer Applications and ipp-usb. As for the Printer 
Applications and ipp-usb the repositories were all the time at OpenPrinting I 
have included the files for snapping them right into their repositories. The 
same I did now also with the files to create the rockcraft-based OCI container 
images, on which Rudra (CCed) has worked in his GSoC project, with Cristovão 
(also CCed) as mentor.

Now we arrived also at the point what to do with CUPS, and my suggestion is to 
not only add the OCI-container-related files to the CUPS 2.x repository "cups" 
but then also migrate "cups-snap" to "cups", so that all the 
distribution-independent packaging methods are included in the "cups" 
repository, where also the code is.

For CUPS 3.x we can then migrate the two packaging methods Snap and OCI 
container over to the two new CUPS daemons, "cups-local" and "cups-sharing", so 
that each of them will be available in the Snap Store but also on OCI container 
image "stores" like DockerHub.

This is Rudra's final report of his GSoC project:

https://medium.com/@rudransh.iitm/gsoc-2024-final-report-container-chronicles-759fe7f23ac6

This is Rudra's repository of the CUPS container image:

https://github.com/rudra-iitm/cups-rock

Rudra's work on the retro-fitting Printer Applications is already in the 
appropriate repositories "ps-printer-app", "ghostscript-printer-app", 
"hplip-printer-app", "gutenprint-printer-app".

Mike, WDYT? Should we migrate the Snap and OCI-image repos into the CUPS one?

    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Michael Sweet]

Till,

We might as well.  However, you should probably also document how you'll manage the versioning since there are so many other components that get packaged with CUPS to make a working snap...  Doing MAJOR.MINOR.PATCH.BUILD versioning is probably sufficient for the snap versioning but it would be nice for users to be able to easily get a list of the bundled components and their versions as well.


> On Dec 20, 2024, at 6:55 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Hi,
> 
> when I started snapping CUPS back in 2017, the CUPS source was still maintained at Apple and therefore I created the separate repo cups-snap at OpenPrinting.
> 
> As I generally recommend that Snaps should be created by the respective upstream projects I am snapping all the projects of OpenPrinting, including CUPS, and also the (retro-fitting) Printer Applications and ipp-usb. As for the Printer Applications and ipp-usb the repositories were all the time at OpenPrinting I have included the files for snapping them right into their repositories. The same I did now also with the files to create the rockcraft-based OCI container images, on which Rudra (CCed) has worked in his GSoC project, with Cristovão (also CCed) as mentor.
> 
> Now we arrived also at the point what to do with CUPS, and my suggestion is to not only add the OCI-container-related files to the CUPS 2.x repository "cups" but then also migrate "cups-snap" to "cups", so that all the distribution-independent packaging methods are included in the "cups" repository, where also the code is.
> 
> For CUPS 3.x we can then migrate the two packaging methods Snap and OCI container over to the two new CUPS daemons, "cups-local" and "cups-sharing", so that each of them will be available in the Snap Store but also on OCI container image "stores" like DockerHub.
> 
> This is Rudra's final report of his GSoC project:
> 
> https://medium.com/@rudransh.iitm/gsoc-2024-final-report-container-chronicles-759fe7f23ac6
> 
> This is Rudra's repository of the CUPS container image:
> 
> https://github.com/rudra-iitm/cups-rock
> 
> Rudra's work on the retro-fitting Printer Applications is already in the appropriate repositories "ps-printer-app", "ghostscript-printer-app", "hplip-printer-app", "gutenprint-printer-app".
> 
> Mike, WDYT? Should we migrate the Snap and OCI-image repos into the CUPS one?
> 
>   Till
> 
> 
> 
> 
> 

________________________
Michael Sweet

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

On 12/21/24 22:06, Michael Sweet wrote:
  > We might as well.  However, you should probably also document how you'll 
manage the versioning since there are so many other components that get packaged 
with CUPS to make a working snap...  Doing MAJOR.MINOR.PATCH.BUILD versioning is 
probably sufficient for the snap versioning but it would be nice for users to be 
able to easily get a list of the bundled components and their versions as well.

The versioning is the same as distribution do when the package upstream 
software. They take the upstream release number and add an integer number 
separated by a dash, the package release number:

CUPS 2.4.12-1

When a new release of the package is done because of a new upstream release 
being used, the new upstream release number is used and the package release 
number is reset to 1.

When a new release of the package is done due to any other change, like a bug 
fix in packaging, a backport of a selected upstream (security) bug fix, ... the 
package release number gets bumped.

So it is practically the same as you suggest.

In our case with the CUPS Snap and also the CUPS Rock, we do practically the 
same, and as the principal upstream component of these packages is CUPS, CUPS is 
the donor of the upstream release number, so we have always the upstream release 
number of the CUPS in use before the dash. On any other change, including 
updates of the upstream releases of any of the other included upstream 
components, like Ghostscript for example, we bump the package release number.

The Snap and the Rock have some maintenance automation:

- Update automation: Every 24 hours a GitHub workflow checks whether any of the 
upstream components has issued a new release. If so, the instruction file for 
building the package (snapcraft.yaml, rockcraft.yaml) gets updated to use the 
new release for the package build and the updated file gets pushed into the GIT 
repository.

- Versioning automation: On each commit, both manual commits and commits done by 
the update automation, the version number is updated. If the commit has updated 
to using a new upstream release of the principal component (CUPS in our case), 
the upstream release number is updated appropriately and the package release 
number is reset to 1. On any other change, the package release number is bumped. 
The new version number is then put into the instruction file and the instruction 
file committed. After that the auto builds for the Snap Store and the DockerHub 
are triggered. So this way the auto-uploaded packages are clearly versioned.

The GitHub workflows for that are currently done by the Snap maintenance GitHub 
action of the Ubuntu Desktop Team at Canonical:

     https://github.com/ubuntu/desktop-snaps

It is planned to merge this action with the one of the Snapcrafters, a volunteer 
organization snapping applications:

     https://github.com/snapcrafters/ci

For an overview of component versions we should perhaps do a CI automation to 
keep a list in README.md updated. This could be added to the mentioned GitHub 
actions or its merger.

One would need to mark a spot in README.md, for example by a headline like

## Included components

and the automation should take all the version numbers which are under 
observation by the update automation. The update automation could actually do 
this step of generating the list and then not only update the package build 
instruction files for using the new upstream versions but also update README.med 
to have the current component version list.

So README.md will contain:

## Included components
- CUPS 2.4.12
- Ghostscript 10.04.1
- libcupsfilters 2.1.0
- libppd 2.1.0
- cups-filters 2.1.0
- ...

Rudra, Soumyadeep, could you add this automation?

I think, this way we will have a user-friendly and easy-to-maintain solution.

    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Michael Sweet]

Till,

> On Dec 21, 2024, at 4:55 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 12/21/24 22:06, Michael Sweet wrote:
> > We might as well.  However, you should probably also document how you'll manage the versioning since there are so many other components that get packaged with CUPS to make a working snap...  Doing MAJOR.MINOR.PATCH.BUILD versioning is probably sufficient for the snap versioning but it would be nice for users to be able to easily get a list of the bundled components and their versions as well.
> 
> The versioning is the same as distribution do when the package upstream software. They take the upstream release number and add an integer number separated by a dash, the package release number:
> 
> CUPS 2.4.12-1

I thought that snap used semantic version numbering?

WRT the rest of the stuff you wrote, let's make sure to add this as documentation ("SNAPCRAFT.md" or something similar at the top) so it is clear how CUPS is being packaged for snapcraft.

________________________
Michael Sweet

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Michael Sweet]

Rudra,

Just to be clear, this is a separate README.md for the snap and not the repository's main README.md file?


> On Dec 22, 2024, at 4:23 AM, Rudra Pratap Singh <rudransh.iitm@gmail.com> wrote:
> 
> Building on your suggestion, I believe implementing automation to maintain a component version list in README.md is an excellent idea. This enhancement would provide users with a transparent and up-to-date overview of the included components, making it easier to track changes and understand the current state of the package.
> Here’s how I propose approaching this:
>     • Marking the Spot in README.md:
> We can designate a specific section in the file, such as:
> <!---->
> ## Included Components
> <!---->
> 
>     • Updating the Section During Workflow Runs:
> When the workflow runs, it can update the section to something like this (and will auto update as versions are changed):
> <!---->
> ## Included Components 
> - CUPS 2.4.12 
> - Ghostscript 10.04.1 
> - libcupsfilters 2.1.0 
> <!---->
> 
> I can try implementing this either in the https://github.com/ubuntu/desktop-snaps repository or in the https://github.com/snapcrafters/ci repository once it’s included.
> Best regards,
> Rudra
> 
> On Sun, Dec 22, 2024 at 3:25 AM Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 12/21/24 22:06, Michael Sweet wrote:
>   > We might as well.  However, you should probably also document how you'll 
> manage the versioning since there are so many other components that get packaged 
> with CUPS to make a working snap...  Doing MAJOR.MINOR.PATCH.BUILD versioning is 
> probably sufficient for the snap versioning but it would be nice for users to be 
> able to easily get a list of the bundled components and their versions as well.
> 
> The versioning is the same as distribution do when the package upstream 
> software. They take the upstream release number and add an integer number 
> separated by a dash, the package release number:
> 
> CUPS 2.4.12-1
> 
> When a new release of the package is done because of a new upstream release 
> being used, the new upstream release number is used and the package release 
> number is reset to 1.
> 
> When a new release of the package is done due to any other change, like a bug 
> fix in packaging, a backport of a selected upstream (security) bug fix, ... the 
> package release number gets bumped.
> 
> So it is practically the same as you suggest.
> 
> In our case with the CUPS Snap and also the CUPS Rock, we do practically the 
> same, and as the principal upstream component of these packages is CUPS, CUPS is 
> the donor of the upstream release number, so we have always the upstream release 
> number of the CUPS in use before the dash. On any other change, including 
> updates of the upstream releases of any of the other included upstream 
> components, like Ghostscript for example, we bump the package release number.
> 
> The Snap and the Rock have some maintenance automation:
> 
> - Update automation: Every 24 hours a GitHub workflow checks whether any of the 
> upstream components has issued a new release. If so, the instruction file for 
> building the package (snapcraft.yaml, rockcraft.yaml) gets updated to use the 
> new release for the package build and the updated file gets pushed into the GIT 
> repository.
> 
> - Versioning automation: On each commit, both manual commits and commits done by 
> the update automation, the version number is updated. If the commit has updated 
> to using a new upstream release of the principal component (CUPS in our case), 
> the upstream release number is updated appropriately and the package release 
> number is reset to 1. On any other change, the package release number is bumped. 
> The new version number is then put into the instruction file and the instruction 
> file committed. After that the auto builds for the Snap Store and the DockerHub 
> are triggered. So this way the auto-uploaded packages are clearly versioned.
> 
> The GitHub workflows for that are currently done by the Snap maintenance GitHub 
> action of the Ubuntu Desktop Team at Canonical:
> 
>      https://github.com/ubuntu/desktop-snaps
> 
> It is planned to merge this action with the one of the Snapcrafters, a volunteer 
> organization snapping applications:
> 
>      https://github.com/snapcrafters/ci
> 
> For an overview of component versions we should perhaps do a CI automation to 
> keep a list in README.md updated. This could be added to the mentioned GitHub 
> actions or its merger.
> 
> One would need to mark a spot in README.md, for example by a headline like
> 
> ## Included components
> 
> and the automation should take all the version numbers which are under 
> observation by the update automation. The update automation could actually do 
> this step of generating the list and then not only update the package build 
> instruction files for using the new upstream versions but also update README.med 
> to have the current component version list.
> 
> So README.md will contain:
> 
> ## Included components
> - CUPS 2.4.12
> - Ghostscript 10.04.1
> - libcupsfilters 2.1.0
> - libppd 2.1.0
> - cups-filters 2.1.0
> - ...
> 
> Rudra, Soumyadeep, could you add this automation?
> 
> I think, this way we will have a user-friendly and easy-to-maintain solution.
> 
>     Till
> 

________________________
Michael Sweet

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

On 12/22/24 14:43, Michael Sweet wrote:
> Rudra,
> 
> Just to be clear, this is a separate README.md for the snap and not the repository's main README.md file?
> 

In the repositories for the Printer Applications and for ipp-usb we have 
described the packaging methods in sections of the main README.md. The lists of 
upstream component versions used will have to go into the appropriate sections, 
one list for the Snap, another list for the Rock.

There is no problem to have the documentation files for the packaging methods 
separate, or short sections (with version lists) in the main README.md and long, 
in-depth documentation in separate files.

Then the automation should also support:

- Having separate component version lists for the Snap and for the Rock in the 
same file

- Having the component version list in more than one file (for example README.md 
and a separate documentation file for the Snap)

    Till


    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Michael Sweet]

Till,

Given that the "component versions" are *not* part of the core CUPS software, putting them in the README.md file would be confusing.  We have an INSTALL.md file for generic installation instructions and dependencies, and in other repositories I have included DOCKER.md and SNAPCRAFT.md files that document both how to use and what is included in those forms.

I would strongly prefer that we keep any component versions separate from the general documentation - prerequisites are normally "version X.Y or later" in the generic build documentation (i.e. INSTALL.md) while specific packages will document/depend on specific versions of components.


> On Dec 22, 2024, at 9:03 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 12/22/24 14:43, Michael Sweet wrote:
>> Rudra,
>> Just to be clear, this is a separate README.md for the snap and not the repository's main README.md file?
> 
> In the repositories for the Printer Applications and for ipp-usb we have described the packaging methods in sections of the main README.md. The lists of upstream component versions used will have to go into the appropriate sections, one list for the Snap, another list for the Rock.
> 
> There is no problem to have the documentation files for the packaging methods separate, or short sections (with version lists) in the main README.md and long, in-depth documentation in separate files.
> 
> Then the automation should also support:
> 
> - Having separate component version lists for the Snap and for the Rock in the same file
> 
> - Having the component version list in more than one file (for example README.md and a separate documentation file for the Snap)
> 
>   Till
> 
> 
>   Till
> 

________________________
Michael Sweet

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

On 12/22/24 15:44, Michael Sweet wrote:
> Till,
> 
> Given that the "component versions" are *not* part of the core CUPS software, putting them in the README.md file would be confusing.  We have an INSTALL.md file for generic installation instructions and dependencies, and in other repositories I have included DOCKER.md and SNAPCRAFT.md files that document both how to use and what is included in those forms.
> 
> I would strongly prefer that we keep any component versions separate from the general documentation - prerequisites are normally "version X.Y or later" in the generic build documentation (i.e. INSTALL.md) while specific packages will document/depend on specific versions of components.
> 

OK, let us do so. That makes it much easier to find the correct information, 
README.md is getting long otherwise and similar info in the Snap and Docker 
parts can get easily confused.

    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

On 12/22/24 16:26, Rudra Pratap Singh wrote:
> To clarify, the feature to update the README.md file is not currently available 
> in the desktop-snaps action. To implement this, I would need to dive into their 
> codebase (which I am already familiar with) and make modifications to suit our 
> specific requirements.
> 
> Whether this concerns the repository's main |README.md| file or a separate one 
> for the packaged CUPS, I will ensure it is tailored appropriately.
> 
> Best regards,
> Rudra

You could make an entry (a comment) in snapcraft.yaml and rockcraft.yaml which 
is/are the files to create the component version list in or just search files in 
the base directory of the repo and in the directory where the *craft.yaml is in 
whether they have the appropriate "## Included Components" mark and then 
auto-update these files.

    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Till Kamppeter]

On 12/22/24 16:37, Rudra Pratap Singh wrote:
> It would be easier to pass the path of the README (or any Markdown file) where 
> we want to list the parts, directly in the workflow itself.

OK, yes, you are right. We have the workflow in each repo with automation ... 
Let us do it this way.

    Till

Re: Merge repositories for CUPS Snap and CUPS OCI/Docker Container into the CUPS repo itself

[Michael Sweet]

Rudra,

Thanks for this, and at first blush it looks really good.  I'll have some time tomorrow to do a deeper review tomorrow...


> On Jan 13, 2025, at 8:31 AM, Rudra Pratap Singh <rudransh.iitm@gmail.com> wrote:
> 
> I have raised a PR (#1137) in the CUPS main repository that includes all the code and configurations for both CUPS-Rock and CUPS-Snap. These are organized within the packages directory.
> 
> Regards,
> __________
> Rudra
> 
> On Mon, Dec 23, 2024 at 3:36 PM Rudra Pratap Singh <rudransh.iitm@gmail.com> wrote:
> I have raised a PR (#840) in the desktop-snaps repository. This PR implements our use case of updating the README (or any Markdown file) to include a list of parts. This needs to be reviewed by Sergio Costas Sir.
> 
> On Sun, Dec 22, 2024 at 9:11 PM Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 12/22/24 16:37, Rudra Pratap Singh wrote:
> > It would be easier to pass the path of the README (or any Markdown file) where 
> > we want to list the parts, directly in the workflow itself.
> 
> OK, yes, you are right. We have the workflow in each repo with automation ... 
> Let us do it this way.
> 
>     Till
> 

________________________
Michael Sweet