[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#688896: Bad idea?



Hi Colin,

On 15-07-13 06:55, Colin Alston wrote:
> On Mon, Jul 15, 2013 at 12:48 AM, Wouter Verhelst <w@uter.be
> <mailto:w@uter.be>> wrote:
> 
>     However, that is not what fpm is. Instead, fpm is a tool to convert
>     packages from one format to another. That, itself, is not necessarily a
>     bad idea either; case in point, we do have a package in Debian, "alien",
>     which provides similar functionality.
> 
> 
> That is not what fpm is.

Yes, it is. Conceptually, it converts data from one format into another.
It's just that it also considers "a DESTDIR style directory of compiled
software" as a "format", hence allows you to _also_ package from scratch.

As a tool, it is much more similar to alien than it is to dpkg.

[...]
>     What makes fpm a bad idea is that it seems to be based on a stance of
>     "Debian Policy is just too hard, and I can't be bothered trying to
>     implement things so they will follow that policy".
> 
> 
> And fpm is not even pretending to create packages which will be included
> into Debian, that's not its use case.

Which is fair enough, and I'm not saying it should be. Evince, for
another example, is also a tool in Debian to create packages, but not
packages that would be included into Debian.

> That aside however, if there is
> some explicit part of how fpm works which results in a .deb file which
> does not conform to "Debian Policy" (whatever that is)

since you ask: <http://www.debian.org/doc/debian-policy>

> then perhaps file
> a bug as to what the details of that is - just as long as that bug isn't
> "fpm isn't dpkg".

Because of the way in which fpm was written, such bugs are almost going
to be a given.

I realize (and agree!) that for local packages, there are parts of
Debian Policy that aren't all that important. To name just one example,
Debian Policy requires that you compress files in /usr/share/doc; if you
don't want to bother with that for local packages, then that won't break
anything.

But there are parts of policy that bits of the Debian infrastructure
depend on; and by ignoring those, things will break in subtle and
complicated ways. If you're going to reimplement the packaging
toolchain, you're almost certainly going to miss those.

>     If the author says he believes maintainer scripts are "almost always
>     poorly written shell scripts that break easily"[1], and combining that
>     with the fact that parts of Debian's infrastructure require stuff being
>     called from maintainer scripts in order to do something properly, then
>     that does not inspire much confidence in the resulting packages.
> 
> 
> Well? In my experience too the Debian scripts are poorly maintained and
> documented worse still - I can't imagine what Joe Public would think.

That's an opinion, and one that does not match my experience.

Most maintainer scripts consist of shell snippets generated/shipped by
debhelper. These snippets have been tested extensively, and are *not*
poorly maintained, by any definition.

There are of course some that are manually written, and of those I grant
you that some will be poorly maintained. But those are not, by any
means, a majority.

> Good software is simple software. Dpkg, dh-make, and all their friends
> are far from good software,

Well, if that's your opinion, we haven't got much more to discuss, really.

> which thus does not inspire my confidence in
> opinions about new tools from those who wrote them unless they can point
> to actual technical failures rather than "policy".

I can't do that, because I haven't actually used fpm.

However, as a long-time and experienced Debian Developer, I can say that
what dpkg does is not some trivial thing. It's certainly possible to
build a debian package by bypassing all that; but it just feels wrong.
The right way is not to throw away the tools, but to pass the right
options and environment variables to get them to do what you want, and
to use the tools that were built for this.

The worst part is that for the case of rpm packages, fpm _actually does
the right thing_ and builds the package using rpmbuild. This is probably
because contrary to dpkg, the rpm format is a special-case one, that
cannot easily be built by other tools; but it does show that it is
possible to build something like fpm _without_ bypassing the tools that
were built for this purpose.

Finally, I'd like to say that while I do believe it's a bad idea, I'm
not necessarily opposed to someone uploading it into Debian. I don't
think we need it, I don't think it's a good idea, and I think it's going
to be a time sink for whoever decides to maintain it for Debian; but if
you want to do that and prove me wrong, hey, more power to you.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


Reply to: