Hi thanks for comments; I reply once to all comments posted ;) > On Tue, 2005-12-20 at 12:08 -0800, Jeremy C. Reed wrote: >> I don't think it is worth it since you'd end up having to recreate a >> packaging system -- complete with diffs, custom configuration args, >> installation work-arounds, et cetera as it used more wide-spread. >> > > I second that. the problem is that many projects does not ship anything else from the raw source package. I'm a developer and I work on various OS projects so I know that it's not easy to provide many packages. Often because it's not so easy to make them and also because they are platform- and even worse distro- specific ! >> As a packages framework and package developer, I have seen numerous >> source >> downloads that install to their own desired locations, overwrite files, >> destroy configurations, have out-dated or non-standard autoconf >> ./configure usage, etc. >> > > And as a Linux user, I've seen that compiling a package from source is > always *not* as simple as a: > > $ ./configure && make && sudo make install yes, it would be wonderful if it always was so pleasant install new software. It's not always but I guess a good 70-80% is. > IMO, if the above set of commands do the job, then why to take the > *trouble* of compiling from source? A binary package would do that for > me. :) what if the binary package doesn't exist ? > I (and I'm sure most other people) compile from source because I need > all binaries and libs in one particular location (for easy removal and > management) or behave in a particular manner. Both of these requirements > are meant by providing required switches to ./configure. I don't think a > GUI would help in such cases. :) the GUI could provide a simple "./configure --help" parser which lets you to browse the configure options before compiling... About the fact that source compiling often confuse other package managers, I cannot say anything: it's true. Unfortunately most programs do not have any support for these package managers... Still I think it's worth to make it a little bit easier for the users source-compiling. Autopackages are a great thing. I want to try them out ASAP and maybe create some autopackage myself. Unfortunately, *if* (hope so) it will become a "standard" for packaging in linux world, this will take time. Meanwhile I have to do the same routine million times ;) Francesco question OT: does anyone know if autopackage is going to be supported by major distro like debian,fedora,suse, etc ? "B S Srinidhi" <srinidhi-gnome@xxxxxxxxxxxxxx> ha scritto nel messaggio news:1135145539.4416.12.camel@xxxxxxxxx > Hi, > > On Tue, 2005-12-20 at 12:08 -0800, Jeremy C. Reed wrote: >> I don't think it is worth it since you'd end up having to recreate a >> packaging system -- complete with diffs, custom configuration args, >> installation work-arounds, et cetera as it used more wide-spread. >> > > I second that. > >> As a packages framework and package developer, I have seen numerous >> source >> downloads that install to their own desired locations, overwrite files, >> destroy configurations, have out-dated or non-standard autoconf >> ./configure usage, etc. >> > > And as a Linux user, I've seen that compiling a package from source is > always *not* as simple as a: > > $ ./configure && make && sudo make install > > IMO, if the above set of commands do the job, then why to take the > *trouble* of compiling from source? A binary package would do that for > me. :) > > I (and I'm sure most other people) compile from source because I need > all binaries and libs in one particular location (for easy removal and > management) or behave in a particular manner. Both of these requirements > are meant by providing required switches to ./configure. I don't think a > GUI would help in such cases. :) > > Srinidhi. _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
