On 11/11/06, Neil Tiffin <[EMAIL PROTECTED]> wrote: > > On Nov 11, 2006, at 12:23 PM, William Scott wrote: > > > 1. Is there in fact significant dissatisfaction? (Lots of people > > use alternatives like MacPorts, but that doesn't mean that they have > > all rejected fink. If someone uses an alternative, or does stuff > > manually, as a matter of taste, I personally don't think we should > > waste time worrying about this. If people are finding fink too obtuse > > or cumbersome or out of date or limited or whatever, especially if > > for reasons that are either a matter of perception or are easily > > fixed, that is another matter.) > > I am a package maintainer without repository access and have used > fink exclusively since Christoph was leading the project. I only use > the unstable tree because that is where the packages I need are located. > > My points: > > - It is a pain to get packages updated if you do not have repository > access. Please do not take that as negative, when others have time > they have helped me greatly and I have had to learn a lot about > packaging. But the simple fact is that when I have time to devote to > fink, others that I depend on to get packages posted don't. The > result is that I usually put together the packages I need and do not > get around to posting them to fink. I have limited time and if it is > not easy to send my work back to fink, then it does not get done. > > - There is no clear process for getting repository access.
Agreed. However, one thing that I haven't seen is somebody actually -asking- to get commits access on this list or on -core or on the IRC channel, so that the criteria would be explained. The main informal criterion is that a prospective person demonstrates an understanding of Fink policies by not putting stuff on the tracker that takes many man-hours of iteration to work into shape. For example, we don't want somebody to commit a package "into the wild" that does things like install files in the main filesystem rather than its .deb build directory. If somebody's packages consistently show that they've validated them and built them under --build-as-nobody, that helps make a case to grant them commits access. We don't expect users to validate their packages. > > - Fink has gotten way too complicated. In the beginning if I needed > to install postgreSQL, fink installed one package. Now it is not > uncommon to select one package to install and have it install many > entries in the fink list (not including dependencies). For > postgresql81 you have 3 packages, postgresql81, postgresql81-dev, > and postgresql81-shlibs. For svn you have svn, svn-client, svn-dev, > svn-doc, svn-shlibs . Who cares. I believe fink has sacrificed use- > ability in order to micro manage dependencies. That said I am sure > there are good reasons for the direction fink has taken, but why do I > care if svn-doc is installed or not? Why do I care of svn-shlibs is > installed or not. You would if you were installing a package that built against svn but didn't need the runtime components. And as a user you'd want to install "whatever-it-is-that-builds-against-the-svn-libraries", which would also have you install svn-shlibs. You wouldn't have to install the client, server, etc. Moreover the big reason to have the -shlibs and -dev splitoffs is ideally to keep from breaking a metric ton of packages if you update a shared library which happens to be binary incompatible with the prior version. You can generate -shlibs packages for different libversions (foo2 alongside foo1) of a package that can coexist while maintainers switch their packages over from foo2 to foo1; and you need the -dev packages to point to them. I don't. I don't even care of svn (server) is > installed. Yet, if I remove a package guess what, I have to remove > each one individually (and I know about the recursive option, but my > job is not fink maintenance and I am unsure how it works and don't > have time to make sure it does not screw up my computer). > Personally, I am in the process of moving key packages to packaged > installers in spite of that removing the best thing about fink. That > is that everything is installed in /sw. > You don't care about tracking where all of the files are? I guess .bom files are OK for that. > There are 39 postgresql entries listed in the fink list. As a casual > user how am I supposed to know what they all do. postgresql80 has 9, > postgresql81 has 3. Why? > > Simply, I do not care where things are installed, only that they > work. I do not care if I install a few extra MBytes of docs or a few > KBytes of headers. With the size of hard disks these days I can't > image this being of concern to anyone else. Install the files and > get over it. If there are a few special cases, they can navigate to > the directory and delete the headers or docs. Or someone could > create a flag in the configuration that says "install headers" or > "install docs". Either way its use-ability that fink needs. I want > to be able to install one package or remove one package and fink > should take care of everything else. In the fink list I should see > one entry for each package I have asked fink to install and one entry > for every dependency I have approved for installation. If we need 5 > versions (you know -ssl etc.) then fink should asked me which options > I want and install them with the one package. > That would involve using something else than the Debian toolset. Ain't gonna happen quickly. > - The difficulty of using fink and the fact that more and more source > trees are compatible directly with Mac OS X without fink make fink > less relevant. Unless the use-ability is addressed I see this trend > continuing. Fink should remove complexity for the end user, not add > to it. > Yeah, but they frequently do a crappy-ass job of it, such as assuming that /sw is a valid path for libraries/includes on all Macs. Plus, if you plop an arbitrary update of a library package on your system with a new libversion, guess what? You can make -everything- that depends on that lib no longer work again without a rebuild. We try to -remove- complexity for the end-user through the shared libraries policy, for example. And if you build an arbitrary source tree and install it in /usr/local, you have to keep the source tree around to use "make uninstall" to remove the, if that's even supported. Having a centrailzed database to keep track of your files doesn't suck. > - Micro-managing the dependancies means that you have to have a Ph.D. > to write .info files. This also encourages less help. That's what this list is for. There are tons of simple packages with minimal dependencies, no shared libraries, ... that people can play around with. Every user has templates in the form of the existing packages. We have some documentation that could be improved. And I personally make relatively detailed descriptions about items that I find in tracker submissions that need to be changed to conform to Fink policy. And people will bitch even more if you don't micromanage the dependencies if they install something that doesn't work out of the box. We put the onus on the maintainers because otherwise we have to deal with it on the lists. > > - I can't remember suggesting moving one of my packages from unstable > to stable. Why? No one asked, no one provided any feedback, and > having it unstable satisfies my needs. I would probably spend more > time if I knew my packages were being used. Fink should have a > method to track package use (not who, but if). The functionality > should default to off and the fink team should encourage everyone to > turn it on if they want better package maintenance. That way if no > one is using a package, it could be dumped. And if a lot of people > are using the package, I'm sure it would get more frequent updates. > But what users want is binaries, and under the current setup anything that never moves out of unstable will never have an official binary. We do have the Debian "popularity-contest" package, but that requires you to have a working Unix sendmail setup to work. Our PR guy would love to have some such functionality. Actually we probably wouldn't dump unused packages but just carry them on at their current version--it doesn't take any maintainer effort. > I know this sounds a bit negative, its not supposed to be. The fink > team has done a great job and saved me countless hours of figuring > out how to compile packages I needed. But it also takes honesty to > improve. I use and will continue to use and contribute to Fink. > > Neil > > -- Alexander K. Hansen Fink Documenter (still) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
