On 2/11/06, Kevin Horton <[EMAIL PROTECTED]> wrote: > On 10 Feb 2006, at 21:51, Alexander K. Hansen wrote: > > On 2/10/06, Kevin Horton <[EMAIL PROTECTED]> wrote: > >> On 10 Feb 2006, at 07:35, Chris Zubrzycki wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> > >>> On Feb 10, 2006, at 6:27 AM, Kevin Horton wrote: > >>> > >>>> On 9 Feb 2006, at 21:53, William Scott wrote: > >>>> > >>>>> I wonder if it might be worthwhile to have some sort of informal > >>>>> web ring of people who serve their fink along these lines: > >>>>> http://fink.sourceforge.net/doc/advanced/bindist.php?phpLang=en > >>>>> > >>>>> I make mine available to my user community, but as long as the > >>>>> user accepts it (and the associated risks) as-is, and doesn't > >>>>> overwhelm my server, I'd be willing to do that. > >>>> > >>>> I'd be willing to contribute any .debs I have. It would also be > >>>> useful to have a daily script that could check to see which of my > >>>> debs needed copying to the server. > >>>> > >>>> Bandwidth might become a concern though, as something like this > >>>> could become quite popular. > >>> > >>> Popular? yes. Easy? kinda. Secure? no. The reason we haven't done > >>> this yet is because of the ease of making a package that contains > >>> malicious code. It's nothing to make a bunch of debs that contain > >>> trojans that would damage your machine, or give me complete control > >>> of it. I don't recommend doing this unless you know and trust the > >>> person very much. > >> > >> I agree that such a deb distribution system should not be allowed to > >> accept debs from just anyone. But, it should be possible to come up > >> with a short list of people that could contribute debs. > >> > >> Anyone with cvs access should be eligible to contribute debs. Long- > >> time package maintainers without cvs access should be eligible to > >> contribute debs. We wouldn't really need too many people. The most > >> popular packages would probably be installed on many possible > >> contributor's machines. We don't need to provide a deb for every > >> possible package. > >> > >> This doesn't need to be an official fink server, if the project is > >> afraid of the liability. For liability reasons, it would probably be > >> best if the server was not based in the US. > >> > >> Kevin Horton > >> Ottawa, Canada > >> > >> > > > > Why? > > > > It's not "liability" that's the problem, It's "I've installed foo and > > it doesn't work". > > You've got some good points. Additional comments below. > > > 1) Linkage from outside. > > Fink package builds aren't necessarily bulltetproof. It's entirely > > possible for a package to link libraries from /usr/local/lib. > > If we know that having things in /usr/local/lib causes breakage, why > is fink happy to build packages when there are things in /usr/local/lib? > > Perhaps fink should check for anything in /usr/local/lib, and abort > the build. There could be an user configurable default to inhibit > the check of /usr/local/lib for those users who needed to have stuff > there that they were sure would not affect fink. We could have a > policy that such users could not contribute debs to the binary > distribution. >
It's not fink per se, but rather it's how the linker works. There has indeed been discussion about options to deal with /usr/local; another option is to have fink temporarily move it during builds. This one can be detected by the .deb module of "fink validate", I believe, so it's not a killer. > > 2) Missing dependencies. > > This is related to the problem with X11 versions. If a package > > happens to link a shared library that's not in the dependency list, > > the package will be broken at runtime for somebody who has an earlier > > version (or, indeed, doesn't have at all) the package that provides > > this library. > > Is this any different than if the user built from source using > the .info file and later removed the package that provided the > missing dependency? It is a problem with the package, and the > package needs to be fixed. Having a binary distribution of the > unstable tree would probably bring this problem to light earlier so > it will get fixed earlier. This is good. > Completely identical. And I agree. It may also be less of an issue when we get a set of maintainer-relevant scripts--in this case one uses 'otool -L' on every binary file in the package and compares to the dpkg database to see what package on the bulld machine provides each file. > > 3) Other issues. > > This is more important if people had a list of deb sources in their > > sources.list file rather than a central repo. In such a case somebody > > could forget and change something on their box that breaks binaries > > for everbody else. An example of my own; > > > > I build packages on my desktop machine at work and have it set up to > > serve .deb files--mainly so that I don't have to build stuff again for > > my laptop. As I've said, I use xorg, so other people on average > > wouldn't be able to use it. At one point before Tiger came out, I 'd > > given the URI out so that somebody who had xorg installed and was > > having problems building KDE could save some time and use my .debs. > > Fair enough. > > > > A few months passed and I'd forgotten about that. I interact with a > > lot of people on the lists and on IRC. Tiger came out and I upgraded. > > My APT server was just set up to point at "dists" so my repo changed > > from pointing to 10.3 .debs to pointing to those that I built on 10.4. > > This didn't matter to me, because I upgraded both my computers nearly > > simultaneously. However, unbeknownst to me, the aforementioned person > > still had my repo in their sources.list but was still on Panther. > > They wound up with a whole lot of broken packages. > > So we would need a central repository(s), tied to a specific > distribution. This differs a bit from Bill's initial idea, but your > experience provides a useful lesson that we should learn. > > I build my packages from source, and then distribute them in our > internal network. So any proposed binary unstable distribution won't > help me. But there seem to be many users who either don't want to > build from source, or are afraid to build from source. A binary > unstable distribution, if properly implemented and maintained, could > be useful to many users. > > Kevin Horton > Ottawa, Canada > > > And I agree: it could be useful. I just want to make sure that people consider the "gotchas" that can occur. One other thing to worry about occurred to me (though it's not too common): If somebody builds in a tree other than /sw their binaries won't be useful on any other machine that doesn't use that path. I believe a major source of concern right now about a dedicated build box is determining who will be the party responsible for it. If that goes forward and the automatic build scripts that Matthew Sachs and others have been working on prove to be robust, then it should be easy to implement automatic generation of a binary distribution at a reasonable interval. An additional option then could be to have a tree to which maintainers can check packages. Then the autobuild would run and try to build all packages in that tree--committers could be informed about problems. -- Alexander K. Hansen Fink Documenter [Day Job] Levitated Dipole Experiment http://psfcwww2.psfc.mit.edu/ldx/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
