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

Re: RFS: fsprotect (try #2)

On Wed, 22 Apr 2009 00:06:23 -0300
Maximiliano Curia <maxy@gnuservers.com.ar> wrote:

> 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.

Just because a package is NEW does not mean it cannot fulfil the
criteria for a native package. All the emdebian-* packages were new in
Lenny and more have been added for Squeeze - all of those are native.

If we get a replacement for defoma, it will (probably) be native
because everyone else already has a native font management package of
their own. The task may seem similar on the surface but if you end up
with one package containing multiple lumps of almost completely
independent code to cope with the idiosyncrasies of each platform then
it is more logical to use native packages for each.

> 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.

There is no point making a native package non-native - all that happens
is that you create an entirely spurious .orig.tar.gz and a
spurious .orig.tar.gz release process and make a new "upstream" release
for every upload and encourage people who aren't running Debian to
think that it's going to work on Fedora or something.

Native packages are GOOD THINGS - they save wasted effort.
> Packaging and coding are, after all, different tasks,

Except when the purpose of the coding is to create packages.

> so using the non-native
> version numbering that makes explicit the "release version" and "packaging
> revision" gives a greater degree of flexibility.

Flexibility without merit is called bloat.

> In cases like giving support to stable, NMUs are easier and cleaner for
> non-native versioned packages.

Not true. The only thing that differs with an NMU is the amount of data
to be uploaded. Big deal.

> 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

That is the correct approach. Ubuntu is not Fedora, it can still handle
a native Debian packages as-is, usually.

Other native packages do not work on Ubuntu - this can be because the
package relies on handling packages from architectures that are not
available in Ubuntu (cross-building, emulators, those kind of packages).

I suppose now you're going to say that debbugs, debian-installer and
wanna-build do not warrant native packages?
> For all these reasons, and many others, even for Debian programs, I think we
> shouldn't use native packages.

Wrong, wrong, wrong. There is and will remain a clear need for native
packages across Debian and NEW packages are just as likely to be native
as any other.

> Neither do I really, but I failed to see what's the gain to use the native
> versioning packaging.

Then look more closely. There is no point creating an abstraction where
none is merited. If a package is so closely tied into Debian that it
cannot hope to support .rpm, then it should indicate this limitation by
being native.
> 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.

It's like porting defoma to gentoo - it isn't going to happen. It
wouldn't be a port, it would be a complete rewrite.

> Should we
> then encourage a fork to their particular system, or help them make fsprotect
> more system independant?

Genuinely native packages cannot be ported, that's the point. The
codebase cannot be made independent.

> Benefiting both systems from mutual improvement is
> something I would look forward to.

You have to accept that this is simply not reasonable or even feasible
for native packages, that is why they are native.

> While tagging it "too specific for my
> system, you can't use it" is not.
> I hope this won't create a huge discussion.

Portability has limits, so native packages are necessary and useful -
sometimes. Most packages should not be native but *some* packages must
be native.


Neil Williams

Attachment: pgphCmTEkn81r.pgp
Description: PGP signature

Reply to: