Svante Signell wrote: > Greetings, > > What do you think of the following proposal: > > In order to simplify for package authors/maintainers and to reduce > duplication, > distribute the source file packages in .tar.gz (or .tar.bz2) format. This > avoids > the need to provide both .tar.gz, .src.rpm and debian source files. > > Included in these tarballs add .spec and .dsc files together with the original > .tar.gz package and .diff.gz files. Then everybody interested can build > source/binary files for their own preferred distribution using the same source > files!!
Many packages already do this. And you need the debian *directory*, not just a .dsc file. This is a good suggestion, but should really be left up to the individual package author. The way to do this, IMHO, is not to write to every list you're on, but to write to authors of software, suggesting they include a .spec file and debian directory, and if you're really motivated, giving them a patch which provides this. Advantages ========== ++ Reduces traffic on multiple lists simultaneously ++ Gives feedback to the person who can act on it ++ Solves the problem you address directly Drawbacks ========= -- Not everyone in the world gets to hear this idea and implement it right away > Another issue is to merge the binary file formats .deb and .rpm :-( Already done, the Debian program alien converts .rpms to .debs. It's harder to go the other way because .debs have more information. Also, file layouts differ, e.g. /etc/init.d vs. /etc/rc.d/init.d, each has its valid reasons and probably won't change anytime soon; translators need to take this into account. More broadly, why is diversity such a big problem? Proprietary software can use autoconf to look for files in different places and release for different distros as easily as free software authors can, right? And the exercise in cleaning up code to do this helps authors of all kinds easily port to other platforms, such as 64-bit, reversed-endian, *BSD, the proprietary Unices, resulting in a larger market, right? Oliver Elphick wrote: > The obvious problem I see, is that this needs a new central repository where > someone, or some automatic process, put together all the elements into > one. How about, like, the author of the package? > Take, for example, PostgreSQL, one of my packages. > > I download its source from postgresql.org and build the new package; later I > fix > bugs and put up a new Debian release. Presumably Lamar Owen is doing the > same kind > of thing for the rpms. However, I don't have the latest rpms and he doesn't > have > the latest debs; neither are interested in the other's product. Who is to > put all > the elements together and make sure they are up to date and that they stay up > to > date? You mean you don't send your patches upstream? I would think (I would hope) the original author is interested in both products, and would take patches from both you and Lamar Owen, possibly including .spec files and the debian directory. > Then consider if someone loads an experimental version of the same package; > the > ordinary version is still current in unstable, but now there is another > version in > experimental; and what happens to all the older stuff in stable? Where do > those > debs go? I've built several packages from source, all you have to do is use dselect to put a hold on the new version so it doesn't "upgrade" to the version in unstable. Or am I missing something? Zeen, -Adam P.
