Re: [Fink-devel] Fink Package Version Checking
At 18:19 Uhr -0400 16.04.2002, Kyle Moffett wrote: On Tuesday, April 16, 2002, at 06:00 PM, Max Horn wrote: At 17:54 Uhr -0400 16.04.2002, Kyle Moffett wrote: On Tuesday, April 16, 2002, at 09:46 AM, Max Horn wrote: At 6:42 Uhr -0400 16.04.2002, Kyle Moffett wrote: I feel kind of stupid now, but maybe something where Fink could update itself to the latest cvs would be helpful fink selfupdate-cvs It's already there. All essential packages (including Fink) are automaticall updated if you run it Also, binary distro doesn't involve the Fink package manager at all, hence such a field as you propose wouldn't do anything with regards to the bindist. And there is no need for it either, since the new binaries work fine with the old package manager. I think you misinterpreted my idea, let me try to rephrase it: Let's say that we need a new tag 'Foo:' for some packages. The tag is made, added to pm cvs and everything is OK. The problems come when somebody using unstable cvs packages tries to install a package using that tag. At the moment fink will fail with some weird error (Depending on the tag and its purpose). Well, if they do it the right way (using fink selfupdate-cvs), then Fink will already be updated! Fink is usually no more than a couple of days in unstable only. And in any case, if you mess with unstable, you bear the risks. Yes, but it is sometimes a week or two when new features are in cvs but not available as a package. fink selfupdate-cvs only updates from the /fink/packages tree in cvs. The /fink/fink tree is ignored. Uhm - yes and that has good reasons. Features of a not yet released Package manager are not to be used in any package in the package tree! They are only to be used for experiemental packages. I was suggesting that instead, all packages needing features not present in the latest released package manager could be identified by 'Depends: fink-cvs (= #date#)' or 'NeedsFinkCVS: #date#'. We do this already, though with BuildDepends. Yes, but if it depends on features only available in cvs, the versioning fails. Some packages might need a newer version of fink, but if the version isn't available as a tarball, it cannot be obtained except by the cvs tree /fink/fink. Wrong. This doesn't happen, and if it does, it's by mistake of the package maintainer who then should immediatly revoke the faulty package. Then Fink could by default ignore packages in CVS (stable or unstable) that have a non-cvs version or a cvs version older than #date#. Then an optional tag could be set in fink.conf for developers and beta testers. This tag would tell Fink to ask the developer if they want to update the fink pkg manager from cvs on the detection of such a package. Well, why? a) developers should also use fink selfupdate-cvs Yes, but selfupdate-cvs does not upgrade the package manager version that is still in cvs. True. If you have to use that (because you are developing a package based on new features). It's a three line procedure to update the PM manually. This is not a very long time, but occasionally I see mails asking why a package errors out with new tags that should work or some new feature doesn't seem to exist (Because the developer/beta tester didn't update the pkg manager from cvs.) If you encounter that *with packages from the official package tree* in the future, please immediatly report these buggy packages so that they can be removef rom CVS ASAP. Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] holding back package upgrade (was: Callingmozilla)
At 2:58 Uhr +0200 17.04.2002, Kilian Koepsell wrote: On Tue, Apr 16, 2002 at 05:30:55PM -0400, Chris Devers wrote: [...] Type: bundle Depends: xfree86-base (= 4.2.0-4), xfree86-rootless (= 4.2.0-2) Description: Prevents automatic update... It's an interesting strategy, but still kind of a pain. I like the earlier thought about --no-update=mozilla, except that it's stateless (have to remember to do it every time) and it seems like feeding it a list (gtk, qt, mozilla, etc other long ones like that) would be stretching what a flag like that should really be accomodating. Maybe a stub file, or a stub field in fink.conf, can have packages to exclude from updates, being a wrapper around a hack like the one JFM suggests [1] of creating a dummy package descriptor, and maybe a new fink exclude ... sub-command can be used to create the list in the first place. hi, i like that idea. what about a command like fink hold mozilla Maybe we do this which checks for the latest mozilla version, say 0.9.9-4, then creates a new file hold-mozilla-0.9.9-4.info containing the above mentioned few lines and installs the package hold-mozilla-0.9.9-4. ... but certainly not this way! That's a hack, and has all sorts of problem (I am not going to list them all here now, I have to go to university). The proper way is to add a seperate file/DB for this to Fink where it keeps track of this information. Also we'd need a reverse release or so command. There are many better ways to do this than to introduce fake packages. Still this doesn't mean I say it'll be added like this. Submit a feature request if you like. Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] holding back package upgrade (was: Callingmozilla)
On 17/4/02 5:35 PM, Max Horn [EMAIL PROTECTED] wrote: At 2:58 Uhr +0200 17.04.2002, Kilian Koepsell wrote: On Tue, Apr 16, 2002 at 05:30:55PM -0400, Chris Devers wrote: [...] Type: bundle Depends: xfree86-base (= 4.2.0-4), xfree86-rootless (= 4.2.0-2) Description: Prevents automatic update... It's an interesting strategy, but still kind of a pain. I like the earlier thought about --no-update=mozilla, except that it's stateless (have to remember to do it every time) and it seems like feeding it a list (gtk, qt, mozilla, etc other long ones like that) would be stretching what a flag like that should really be accomodating. Maybe a stub file, or a stub field in fink.conf, can have packages to exclude from updates, being a wrapper around a hack like the one JFM suggests [1] of creating a dummy package descriptor, and maybe a new fink exclude ... sub-command can be used to create the list in the first place. hi, i like that idea. what about a command like fink hold mozilla Maybe we do this which checks for the latest mozilla version, say 0.9.9-4, then creates a new file hold-mozilla-0.9.9-4.info containing the above mentioned few lines and installs the package hold-mozilla-0.9.9-4. ... but certainly not this way! That's a hack, and has all sorts of problem (I am not going to list them all here now, I have to go to university). The proper way is to add a seperate file/DB for this to Fink where it keeps track of this information. Also we'd need a reverse release or so command. There are many better ways to do this than to introduce fake packages. Still this doesn't mean I say it'll be added like this. Submit a feature request if you like. Max I'm pretty sure dpkg (or it might be apt) does this. Through dselect, at least, you can 'hold' a package, and it is simply not upgraded (version or revision) until you 'unhold' it. [ Actually... It's dpkg. Presumably something like 'dpkg --hold package' would do the trick... ] HTH! ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Restrictive licenses - fit for stable=
On Wed, 17 Apr 2002, Max Horn wrote: At 10:22 Uhr -0400 17.04.2002, Chris Devers wrote: On Wed, 17 Apr 2002, Max Horn wrote: the following packages have a Restrictive license: What is the working definition of restrictive? Non-GPL? Non-Berkeley? (Arguably, GPL is much more restrictive than BSD, but somehow I don't think that's a problem in this context). That is completly irrelevant. It's relevant because I wasn't sure what 'restrictive' means here. I wasn't trying to be combative or anything -- I know you're busy and I'm not trying to create more work for you. The question was whether the actual license of each of these packages makes any restrictions on the distributions of binaries. And I got maybe a little too theoretical realized that anything more restrictive than public domain ipso facto places restrictions, thus the comment about GPL v. BSD. I'm still not totally clear on what kinds of restrictions are problematic here... But like I say, I'm not sure what the criteria for restrictive are. Again, this is completly unimportant for answering the original question. I'm sorry, but I thought that is exactly what the original question was. I think I get it now -- I'll go look up policy on the site to be sure. -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ More war soon. You know how it is.-- mnftiu.cc ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] holding back package upgrade (was: Calling mozilla)
hi, Just as a test case, I tried it on SDL.. chose sdl 1.2.3, and hit =. (hold). It showed held in dselect. Then did a fink update-all, and sdl 1.2.4 downloaded, and... dpkg installed it right over 1.2.3. I had assumed it would build the deb and then stop. i used to use the feature under debian and i think the problem is the following: putting a package on hold prevents it to be upgraded when you do an apt-get upgrade but it will still be upgraded if you do expicitely apt-get install packagename anyway, you really need something in fink instead of dpkg if you want prevent fink from recompiling the package. cheers, kilian ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] holding back package upgrade (was: Calling mozilla)
At 9:23 PM +0200 4/17/02, Max Horn wrote: At 11:43 Uhr -0700 17.04.2002, Ben Hines wrote: At 5:54 PM +1000 4/17/02, Jeremy Higgs wrote: I'm pretty sure dpkg (or it might be apt) does this. Through dselect, at least, you can 'hold' a package, and it is simply not upgraded (version or revision) until you 'unhold' it. [ Actually... It's dpkg. Presumably something like 'dpkg --hold package' would do the trick... ] Apparently you're supposed to use dselect to hold stuff. However, it didn't work for me: Just as a test case, I tried it on SDL.. chose sdl 1.2.3, and hit =. (hold). It showed held in dselect. Then did a fink update-all, and sdl 1.2.4 downloaded, and... dpkg installed it right over 1.2.3. I had assumed it would build the deb and then stop. Why should it work, after all the hold command is not part of dpkg, but rather of dselect/apt. From the dpkg manpage: INFORMATION ABOUT PACKAGES dpkg maintains some usable information about available packages. The information is divided in three classes: states, selection states and flags. These values are intended to be changed mainly with dselect. ... PACKAGE FLAGS hold A package marked to be on hold is not handled by dpkg, unless forced to do that with option --force-hold. -Ben -- http://homepage.mac.com/bhines/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Restrictive licenses - fit for stable=
At 15:05 Uhr -0400 17.04.2002, David R. Morrison wrote: Concerning revtex, I have been unable to find any discussion of licensing either within the download or on the web site. I assume that not distributing the binary would then be the default option. Indeed. Maybe somebody can contact them, though, and ask? Would be nice to know, if not for 0.4.0 then for the future. Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
