Re: [Fink-devel] CVS commit rules
On 15/3/02 10:52 PM, "David R. Morrison" <[EMAIL PROTECTED]> wrote: > I'd like to remind all core fink developers of the most important rule when > committing things to CVS: > > IF YOU HAVE MADE ANY CHANGE TO YOUR PACKAGE, YOU MUST INCREASE THE > REVISION NUMBER. > > Like any good rule, there are exceptions to this: you can modify the > Description field, for example, or BuildDepends, because neither of these > will affect an already compiled package. The thing we want to avoid is > different users compiling packages with the same revision number and > getting different results -- that is a disaster for sorting things out > and solving problems later on. > > Fink has had an excellent track record of following this rule, with a few > minor deviations. Let's keep this up. > > -- Dave Hi David, Just to clarify things... A couple of minutes ago, I updated the download URL for qcad (in unstable), due to a report from a user that the previous URL no longer worked. I assume this is OK, as no recompilation of the package is necessary? Thanks! ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glib 2.0
One more things, New packages does not replaces old one automatically. Please remove old packages before installation. On Sat, 16 Mar 2002 13:23:05 +0900 Masanori Sekino <[EMAIL PROTECTED]> wrote: > Renamed packages are in CVS now. They are named glib2, atk1, pango1, > gtk+2, linc1 and libidl2. -- Masanori Sekino mailto:[EMAIL PROTECTED] http://hp.vector.co.jp/authors/VA008857/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] glib 2.0
On Thu, 14 Mar 2002 08:20:31 +0900 Masanori Sekino <[EMAIL PROTECTED]> wrote: > I'll rewrite GTK2/GNOME2 packages and put them into CVS again. Renamed packages are in CVS now. They are named glib2, atk1, pango1, gtk+2, linc1 and libidl2. New packages orbit2 and libart2 are also available. Thanks, -- Masanori Sekino mailto:[EMAIL PROTECTED] http://hp.vector.co.jp/authors/VA008857/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly
okay point taken and I'm game if approved could we add documentation for it on the website. my docs are far behind now with all the new changes :P I'm a paper guy still need to print em :P And BTW it was fink validate that i was referring to with fink check. [EMAIL PROTECTED] writes: >Actually, we can worry about the implementation later. We won't want to >implement this until the later stages of the shared libraries project, >when most packages have been converted over to the new system. However, >it would be good to start using the BuildDependsOnly field now, easier >to put it in now than to go and add it to lots of packages later. > >(The only thing we would need to do immediately would be to add >BuildDependsOnly to the list of allowed fields, so that "fink validate" >doesn't complain about it.) > > -- Dave ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., Justin F. Hallett - Systems Analyst Phone: (780)-408-3094 Fax: (780)-454-3200 E-Mail: [EMAIL PROTECTED] .·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly
the sub heredoc is in the works by Max ATM. for now i think it have to be one long line as far as i know. [EMAIL PROTECTED] writes: >Another thing that occurred to me while packaging is, is there a way to >do multilines inside a splitoff? While making the kdelibs package, I have >a huge line of files in the "Files:" section of the bin and shlibs >sub-packages. Can those be continued with \ at the end, or maybe a sub >heredoc? > >Splitoff: << > Files: > lib/blah.so > ... > ><< ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., Justin F. Hallett - Systems Analyst Phone: (780)-408-3094 Fax: (780)-454-3200 E-Mail: [EMAIL PROTECTED] .·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] sub-heredoc (was Re: BuildDependsOnly)
Benjamin Reed <[EMAIL PROTECTED]> wrote: > Another thing that occurred to me while packaging is, is there a way to > do multilines inside a splitoff? While making the kdelibs package, I have > a huge line of files in the "Files:" section of the bin and shlibs > sub-packages. Can those be continued with \ at the end, or maybe a sub > heredoc? > > Splitoff: << > Files: > lib/blah.so > ... > > << You can do this already. The terminator for the sub-heredoc is also <<, which causes fink warnings, but Max is working on a fix for that. -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly
"Justin Hallett" <[EMAIL PROTECTED]> wrote: > hmmm I can't see why not but instead of adding more to the build time run > add it to the fink check command, which I hope all fauthors are using > right?:P Actually, we can worry about the implementation later. We won't want to implement this until the later stages of the shared libraries project, when most packages have been converted over to the new system. However, it would be good to start using the BuildDependsOnly field now, easier to put it in now than to go and add it to lots of packages later. (The only thing we would need to do immediately would be to add BuildDependsOnly to the list of allowed fields, so that "fink validate" doesn't complain about it.) -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly
David R. Morrison [[EMAIL PROTECTED]] wrote: > I have another small proposal to make related to the long-term shared libraries > project: I suggest that we add a new boolean field BuildDependsOnly. If > it is "true", the package it is in would not be "allowed" to be Depended on > by any other package, only BuildDepends would be allowed. Fink won't > actually enforce this, it will only issue a warning, but it would be a > good method (I think) to remind developers that they are not supposed to > be having another package Depend on this one. > > So, when packaging software with shared libraries, your package "foo" > which contains headers and the libfoo.dylib symlink would say > "BuildDependsOnly: true", while the package "foo-shlibs" would have no > restriction like that. > > Any reactions to this, for or against? Makes sense to me. Another thing that occurred to me while packaging is, is there a way to do multilines inside a splitoff? While making the kdelibs package, I have a huge line of files in the "Files:" section of the bin and shlibs sub-packages. Can those be continued with \ at the end, or maybe a sub heredoc? Splitoff: << Files: lib/blah.so ... << -- Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED]) http://defiance.dyndns.org/ / http://radio.scenespot.org/ ...if humanoids eat chicken, then obviously they'd eat their own species. Otherwise they'd just be picking on the chickens. -- Kryten ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly
hmmm I can't see why not but instead of adding more to the build time run add it to the fink check command, which I hope all fauthors are using right? :P [EMAIL PROTECTED] writes: >I have another small proposal to make related to the long-term shared >libraries >project: I suggest that we add a new boolean field BuildDependsOnly. If >it is "true", the package it is in would not be "allowed" to be Depended >on >by any other package, only BuildDepends would be allowed. Fink won't >actually enforce this, it will only issue a warning, but it would be a >good method (I think) to remind developers that they are not supposed to >be having another package Depend on this one. > >So, when packaging software with shared libraries, your package "foo" >which contains headers and the libfoo.dylib symlink would say >"BuildDependsOnly: true", while the package "foo-shlibs" would have no >restriction like that. > >Any reactions to this, for or against? ¸.·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., Justin F. Hallett - Systems Analyst Phone: (780)-408-3094 Fax: (780)-454-3200 E-Mail: [EMAIL PROTECTED] .·´^`·.,][JFH][`·.,¸¸.·´][JFH][¸.·´^`·., ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] BuildDependsOnly
I have another small proposal to make related to the long-term shared libraries project: I suggest that we add a new boolean field BuildDependsOnly. If it is "true", the package it is in would not be "allowed" to be Depended on by any other package, only BuildDepends would be allowed. Fink won't actually enforce this, it will only issue a warning, but it would be a good method (I think) to remind developers that they are not supposed to be having another package Depend on this one. So, when packaging software with shared libraries, your package "foo" which contains headers and the libfoo.dylib symlink would say "BuildDependsOnly: true", while the package "foo-shlibs" would have no restriction like that. Any reactions to this, for or against? -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Request for Assistance: Packaging for mutella
We're nearing release, and I'd like someone to help me with getting a package ready for mutella. I'm responsible for the port of Mutella to MacOS X, and will be taking over as package maintainer for some time while Max, who's done much of the work up to now, takes a breather from the project. It runs, it's stable, and it's fast. It support 0.6, and I'm going to add GGEP and Ultrapeers for the next version, in all likelihood. It doesn't do swarming, but it will make parallel connections to anyone who offers and take from the fastest, continually checking to see if faster providers come online. It's a nice client. And I'd like to see it more widely used. That means getting it added to fink. It's got a single dependency on libreadline, and it's got a working build system (automake 1.5, autoconf 2.13, needs to have /usr/libexec/config.* copied to the local directory first). I need someone to help in getting a package together, and if anyone has time, maybe to help with testing and report feedback, or by writing a man page. Is there anyone out there who might be willing to provide packaging? Sincerely, Greg Block, co-maintainer, Mutella ( http://mutella.sourceforge.net ) ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] CVS commit rules
I'd like to remind all core fink developers of the most important rule when committing things to CVS: IF YOU HAVE MADE ANY CHANGE TO YOUR PACKAGE, YOU MUST INCREASE THE REVISION NUMBER. Like any good rule, there are exceptions to this: you can modify the Description field, for example, or BuildDepends, because neither of these will affect an already compiled package. The thing we want to avoid is different users compiling packages with the same revision number and getting different results -- that is a disaster for sorting things out and solving problems later on. Fink has had an excellent track record of following this rule, with a few minor deviations. Let's keep this up. -- Dave ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
