2009/10/2 Andrea Bolognani <e...@kiyuko.org>: > On Fri, Oct 02, 2009 at 01:30:58PM +0100, Phil Housley wrote: > >> > With my Debian package maintainer hat on, I kindly ask you _not_ to do >> > that. >> > >> > Upstream development and packaging for a distribution are two totally >> > separated affairs, and mixing them only leads to huge headaches and >> > duplication of efforts. >> >> I see where you are coming from with that, but for me as a lonely >> developer they really aren't separate. I don't want to go the >> autotools route, of having a build tool that can also do installs, and >> then translating an installation into packages and so on. From my >> point of view I'd like to make/download/sync a project, have the build >> tool turn it into something I can install, and then use a package >> manager to install it. > > How is having a build system perform installs a problem? Basically every > build system I know of handles both. Building a software and installing it > are two strictly related tasks, and it's only natural to have the same piece > of software handle both.
Well, running an average make install on Unix sprays data about over 5 or more directories, and leaves you stuck for clearing up, unless you still have the same source checked out and configured the same when you come to uninstall. Not my favourite thing about Unix that, but something package managers have sorted out very neatly. >> Sure, if most devs are like me they won't always be making perfect >> packages that go straight into a distro, but they will shift the job >> of installing things to something that is good at it. >> >> I don't see that it can hurt to have package information in the >> project itself, even if no distro ever wants to use it. Or am I >> missing something there? > > The problem with having support for making packages inside a build system is > that it encourages developers to actually use that support. > > Making a Debian package is not a straightforward task: there's a lot of > things you need to learn before you can make a simple package, one which > contains no shared libraries or similar "complicated" stuff. Maybe I should have chosen a different example, perhaps autopackage or something else more independent than .deb. Anyway, all I was thinking is that I would like to be able build a package of some sort, which would be independent of the source and build tool. I consider making a package to be part of the build process, and using it not to be. > Even assuming making a Debian package out of an upstream source tree was > trivial, what about people using other distributions, with different package > managemen systems? What about people using a *BSD, or Solaris? > > Would you, as an upstream maintainer, be prepared to define a recipe for > every and each of these different package formats? Wouldn't the time spent > doing so best used working on the actual code, instead of a dozen or so > build systems, each one with its different rules and conventions? Probably not, but in a perfect world the package maintainer could maintain a patch set that dropped their specific files into a new unit in the source tree, and then when they ran $ buildtool package They would get a package made of their own source. > Upstream developers should be able to only care about the code. > Distribution-specific issues and quirks are better handled by downstream > maintainers. > > -- > Andrea Bolognani <e...@kiyuko.org> > Resistance is futile, you will be garbage collected. Still, it's all just some ideas at this point. -- Phil Housley _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
