Re: [Printing-architecture] OpenPrinting News

Up to now I have created more or less a working model of the needed 
Printer Applications, to find out what is needed in the library's APIs 
before making releases of the libraries (libcupsfilters, 
libpappl-retrofit). Therefore there are no upstream package releases yet 
but Snaps for everything.

With the Snaps I once wanted to find out whether and how CUPS and the 
Printer Applications work when snapped (or generally sandboxed) and also 
give users a way to quickly download and try out everything without 
needing to compile.

I know that with Snaps I cover many distributions (the systemd-based 
ones) but not all, as some do not use systemd and others have policies 
against Snap, mainly due to the fact that there is currently only one 
Snap Store. So Snap is a good platform to quickly get user response for 
a new project, without the bureaucracy of getting it into a distro and 
without only addressing the users who compile stuff. It also covers many 
distributions and so gets a permanent source for many users, especially 
also for packages (here printer drivers) which are newer than the distro 
release they are using.

What is Arch's situation. Do they not support Snap because they are not 
using systemd or is it because of things like the Snap Store "monopoly", 
or because of being an easy way to install closed-source software,  or 
for other reasons?

Now, as I have put practically all free software printer drivers into 
Printer Applications I know that my library's APIs are good enough for 
the task and so, as you can read in my December news, I am working on 
making the libraries releasable, by testing and debugging them. Then I 
will release cups-filters 2.0.x and pappl-retrofit 1.0.x, and after that 
also spin upstream releases of the 4 Printer Application, making it easy 
for distros to create distro packages in their package format (DEB, RPM, 
whatever Arch uses, ...).

The build systems of cups-filters and libpappl-retrofit are already 
distro-friendly (derived from cups-filters 1.x), so once we have 
releases, creating distro packages should be easy.

The daemons in the Printer Applications are created and controlled by 
the PAPPL library project. Should you run into problems packaging the 
Printer Applications for a distro where PID 1 is not systemd due to the 
starting of the daemon, please report an issue at PAPPL:

https://github.com/michaelrsweet/pappl/issues

This is the state of the art as of now and I naturally want that the 
Printer Applications will be packaged in different formats to cover as 
many distributions as possible and so reach as many users as possible. 
Especially when we are at CUPS 3.x in 2 years, PPD support is dropped in 
CUPS and so everyone will need Printer Applications for non-driverless 
legacy printers, independent of whether there is some sandboxed 
packaging used or not.

We especially need to make sure that printing support in Arch is in a 
good shape so that it "just works" for users. Especially see this video:

https://www.youtube.com/watch?v=TtsglXhbxno&t=9s

So I would much like that the user experience on Arch is the same as on 
Mint, and we from OpenPrinting want to help you on that.

I hope this clarified the situation. Please post if you have any further 
questions.

    Till

On 10/12/2021 21:20, Andreas Radke wrote:
> Hi Till,
> 
> I'm still missing some initial news about how to package printer
> applications in the future as casual distribution packages without the
> snap store. I'm willing to help offering early packages but so far there
> seems to be no way planned without going the snap path. Arch doesn't
> offer any snap support and will never do so.
> 
> -Andy
> Arch Linux
>