Re: Piwigo, Owncloud, ...: doing it not right?
> 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).
The upstream installation process is usually different for each app, and
often sucks (web interfaces for update? really?). Sometimes I feel
like the upstream assumes this app is an important part of your life so
you can afford to take time to follow its development (i.e. it's not
meant for a personal server but for a company-wide server managed by
a professional sysadmin).
Many offer Debian packages, but having a Debian repository instead has
the following advantages:
- one additional repository in my sources.list for N apps, rather than
N additional repositories.
- at least a tiny bit of third-party oversight (I'm willing to give
some trust to upstream(s), but some third party oversight is very
welcome).
- the packager is aware of (and hopefully agrees with) Debian's
philosophy, so the package will presumably make some effort to reduce
friction with Debian. As Christopher Huhn says, I'd expect it to work
as an incubator.
> 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).
Not familiar with Flatpak nor Snappy, but what I've seen of Docker is
not promising in terms of long-term maintenance, since the way to keep
an app up-to-date is rather painful: seems to work well for
a professional sysadmin managing a company-wide installation, but for
myself managing N apps for personal use this looks like an insane amount
of work. I haven't seen anything remotely close to "apt-get
upgrade" there.
>> 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.
By "compatible with DFSG" I meant that it should be Free Software.
> Web stuff often uses compiled HTML/JS/CSS and soon WebAssembly
> and dealing with that is a big part of packaging messy web apps.
I wouldn't require from "messy" packages that they solve those messes.
Only that solving them be possible (i.e. that the source code be
available somewhere).
> Documenting and checking copyright and license information would also
> be required, which is another big part of this.
I think this part of the work is important, OTOH, so contrary to the
previous messes, I would think we'd want this work to be done before
a package can be accepted in the "messy" repository.
IOW, the main criteria for acceptance into "messy" would be:
- Licenses have been checked to ensure it's all Free Software.
- it doesn't mess up a normal install: while it doesn't have to follow
the FHS, it should confine its non-FHS-conforming files to
a harmless area.
> The third aspect is embedded code copies;
Allowing embedded copies would be part of what makes packages "messy", yes.
> with automated conversion of many language-specific packages to Debian
> packages, that work could be reduced.
A "messy" package obviously wouldn't *have to* use embedded copies, so
among the "messy" packages, some would be messier than others.
Stefan
Reply to: