Re: Piwigo, Owncloud, ...: doing it not right?

Hi all,

I was maintainer for piwigo package for many years. It helps a lot as I was also a core member team.

I cannot precisely why I stopped manage that package but I can remember acceptance rules are more and more constrainant. I think about minified stuff (_javascript_, stylesheets) that need to be unminified in debian. Upstream not always understand problem. And it gives maintainers more work to minified them afterwards to have a good visitors experience. Flash is another big problem. I didn't find a solution even if flash's end of life is more and more real !

I don't think using a messy server is a good idea. Working on active project and follow upstream release is not so difficult. The first release is a bit difficult but afterwards it can be done easily.

My two cents.

Nicolas

2017-06-27 6:40 GMT+02:00 Paul Wise <pabs@debian.org>:

On Mon, Jun 26, 2017 at 11:19 PM, Stefan Monnier wrote:

> So I'm wondering what people think here: would there be room for another
> repository (call it `messy`) which would hold extra packages that are
> not well integrated with the rest of Debian. I'm not sure if those
> packages should be installable on top of stable or testing or both
> (probably stable is the most important).

Sounds like you are waiting for the Debian bikesheds/PPAs proposal to
be implemented. Until then, you could create a messy.debian.net
repository for this.

Personally, it seems like a weird idea to me. What would be the
advantage of messy Debian packages over whatever system upstream has
in place for installation and upgrades? I thought that usually those
are fairly well automated using web interfaces already? Some upstreams
already have repos for messy Debian packages (piwik for eg).

In any case, I think the general movement upstream is away from distro
packaging and towards more-standardised upstream-provided "apps" in
various forms (Docker/Flatpak/snappy/etc). If you want messy, I think
using the existing messes is better than spending effort on creating
messy Debian packages.

> Of course, I wouldn't want such a repository to encourage maintainers to
> give up on nicely integrated packages. The intention would be for this
> repository to hold applications which otherwise wouldn't be in Debian at
> all (of course, all those packages would have to be compatible the DFSG).

I think you should drop the DFSG requirement, because then you have to
deal with DFSG item 2, which means tracking down source code for each
item. Web stuff often uses compiled HTML/JS/CSS and soon WebAssembly
and dealing with that is a big part of packaging messy web apps.
Documenting and checking copyright and license information would also
be required, which is another big part of this. The third aspect is
embedded code copies; with automated conversion of many
language-specific packages to Debian packages, that work could be
reduced.

https://wiki.debian.org/AutomaticPackagingTools

--
bye,
pabs

https://wiki.debian.org/PaulWise