Re: RFS: fsprotect (try #2)
Excerpts from Neil Williams's message of mar abr 21 14:53:13 -0300 2009:
> On what basis? apt and dpkg are definitely native packages, as are most
> other packages that use apt and dpkg directly (like emdebian-*).
> Packages that use .deb files in explicit manners are often native too -
> unless they also work with .rpm etc.
I think that a new package shouldn't be native.
There are packages that are native projects as the ones you mention, but
even if they gain the name by being a development that Debian depends on,
there is little gain, if any, in treating them as special cases.
Packaging and coding are, after all, different tasks, so using the non-native
version numbering that makes explicit the "release version" and "packaging
revision" gives a greater degree of flexibility.
In cases like giving support to stable, NMUs are easier and cleaner for
non-native versioned packages. Or in a derivative distribution, if they need
to change a native package, should they build another native or should they
make them non-native one? (for example, ubuntu considers apt as native, with
version 0.7.20.2ubuntu6)
For all these reasons, and many others, even for Debian programs, I think we
shouldn't use native packages.
> Packages that are explicitly tied to a single distribution are native
> to that distribution. What level of tie is deemed to be above a
> threshold sufficient to make the package native is a subject of ongoing
> case-by-case discussion.
> Other packages that are justifiably native include debhelper and the
> like.
> I'm not particularly interested in fsprotect per-se, but I don't see
> that it cannot be deemed native by those who know more about the kinds
> of things it needs to do.
Neither do I really, but I failed to see what's the gain to use the native
versioning packaging.
Let's assume fsprotect is a wonderful project, and works perfectly in Debian.
I'm sure others would notice and some might choose to use Debian for that
reason, but some would prefer to port fsprotect to their systems. Should we
then encourage a fork to their particular system, or help them make fsprotect
more system independant? Benefiting both systems from mutual improvement is
something I would look forward to. While tagging it "too specific for my
system, you can't use it" is not.
I hope this won't create a huge discussion.
--
Saludos,
Maxy
Reply to: