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 0.7.20.2ubuntu6) 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgphCmTEkn81r.pgp
Description: PGP signature