Re: [Fink-devel] BuildDependsOnly field
Am Mittwoch, 03.12.03 um 05:56 Uhr schrieb Ben Hines: it is good to work in CVS. But for major dep engine changes you might want to work in a 'branch' instead, not HEAD. I fully agree with Ben. In fact, I am not happy about the recent addition of BuildConflicts. It seems very half baked to me. Hey, I could have added this way of implementing it a year ago. I had reasons why I didn't. Might be a good idea to first ask the persons who spent a lot of time researching this issue before charging ahead, Justin! Max --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly field
Already stated I will no longer work be working on fink's code base unless it's to fix something that I created. Sorry to try and advance fink instead of complaining yet again about something that has been discuss a dozen times already. I have two branches already they don't work, they have been there for over 6 months, no one tests them and no one merges/updates them. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 4-Dec-03, at 9:01 AM, Max Horn wrote: I fully agree with Ben. In fact, I am not happy about the recent addition of BuildConflicts. It seems very half baked to me. Hey, I could have added this way of implementing it a year ago. I had reasons why I didn't. Might be a good idea to first ask the persons who spent a lot of time researching this issue before charging ahead, Justin! smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
Am Donnerstag, 04.12.03 um 22:36 Uhr schrieb TheSin: Already stated I will no longer work be working on fink's code base unless it's to fix something that I created. That's not what I asked you for, but of course it's your own decision on how you want to react in this situation. Sorry to try and advance fink instead of complaining yet again about something that has been discuss a dozen times already. While I applaud your attempt to fix something which has been discussed a dozen times already, that is no valid excuse to at the same time ignore things which have been discussed a dozen times already. The real problem, however, is what I see by looking over the fink-cvs logs in the past couple days. Essentially you seem to be doing some kind of trial-and-error development on the trunk right now. This is *not* good. Code should be tested before it is committed, not after. Of course it's very easy to overlook a mistake and accidentally commit it, happened often enough to me. But looking at your recent commits and also the commit messages, I get a really bad feeling in the stomach. BTW, changing some fundamental behavior of fink w/o *any* discussion, or at least announcement of that change, on fink-devel, is *really* bad. I have two branches already they don't work, they have been there for over 6 months, no one tests them and no one merges/updates them. I think we have a misunderstanding here about how working on a branch works. A branch is a way to separate and isolate development of potential hazardous features from regular development. Once a feature has been completed and sufficiently tested on a branch, it may be merged back into the trunk, if desired. A branch usually has one or more drivers - persons in charge of that branch. This person or persons develops the branch, and watches any changes made to it (in this scenario this is mostly redundant to mention, but on bigger projects it can easily happen that a branch develops branches of its own. But I digress). The driver is the one who drives testing of the branch, too - that entails getting others to test his branch. The driver may attempt to keep his branch in sync with the trunk to make merging it in the future as easy as possible It also means the driver is the driving force behind getting the branch merged into the trunk. Usually he does so by convincing the trunk maintainers that his changes are stable enough and useful enough to justify inclusion in the trunk. A typical approach to that is that the driver decides his branch is good for go. He then might make a patch against the trunk, and then post that patch in a patch tracker item for review / general testing. As I stated it's the task of the branch driver to get others to test his branch and review it. Including the people responsible for the trunk. It's *not* the task of the trunk drivers to do this (they may do it if they feel like it, of course). So, rather than complaining about you already having two branches which are there for over 6 months, *do something*. Decide whether you want to abandon these branches, or keep caring for them. In the latter case, go and fix them. If you can't do it, actively try to get other people who can fix them to help you. Once your branch(s) are fixed and actually useful, make a patch out of them, post a patch tracker item. Don't forget to put a description of your patch in that item, including an explanation of what the patch does, why it's useful, etc.. Then start prodding me/Ben/drm/etc. to review it. That is an informal overview of how such things usual are handled formally. Of course many things in there can potentially be shortcut, e.g. if you can get trunk maintainers to work together with you on the branch. However, just sitting there and hoping that somebody discovers one of your branches, tests it, makes required fixes for you and completes your code, isn't sufficient. Directly including your changes into the trunk in the hopes that by putting semi-broken code into trunk, people will *have* to fix it for you and complete it, usually is a bad idea. A good example of this is something I did (putting in the fink cleanup code incomplete, in the hopes that somebody else will fix it). As you can see, that didn't work out too well. But at least in this case nobody will have to suffer. Luckily, the BuildConflicts field shouldn't cause suffering either, no matter how it is implemented, as long as it isn't used (and since it's not documented, it won't be used). AFAIK one of your branches was about making passwd obsolete. Very good that you are working on this. The way it was done isn't quite the way I'd have liked to see it done. That wouldn't matter, though, if it worked. As it is, the code doesn't work and is very outdated compared to the trunk. So it's very hard for interested parties to try it out (the lack of any docs doesn't help). As a result, nobody does. If you are really
Re: [Fink-devel] BuildDependsOnly field
I completely agree but shlibs and uidgid have been done since before 10.3 and they are not updated and not merge though I point them out almost weekly. And I got tried of working for nothing, this way it's tested, reported and worked on. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 4-Dec-03, at 3:26 PM, Max Horn wrote: A branch is a way to separate and isolate development of potential hazardous features from regular development. Once a feature has been completed and sufficiently tested on a branch, it may be merged back into the trunk, if desired. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
I did announce this, and hence where Clef's comment came from. And to a degree it's trail and error, but it's tested first it's just that I'm on top of the report, ppl want different output, reading the code essential is passed on the splitoffs from the arent but drm didn't want that to be true in remove so I switched that back, though it worked both ways and wasn't trail and error, my last commit to fix rebuild, well i tested 3 different installs but never thought of rebuild, though I fixed it right away. The only one that was a mickey mouse fix was in the remove code with setting $vo, which I've changed now, thought I still think we need a get_currentversion(), but I didn't want to leave it broken, pogma pointed out that the first way I had it it would remove a pkg if it needed to be upgraded as I was checking for lastest version. And that was an error I needed to fix. so as you see NONE of it was trail and error, just things that needed attention, and I wanted ppl to be able to comment and test it as I go instead of changing all at once, plus I don't want to document any of it yet as it's not ready to be used, ie BuildConflicts, I want the devel team to test it more before the public knows about it. Anyhow, I'm publicly sorry and a jack ass, and I'm done, this is odd, from the other 12 conversations on this topic the problems with buildconflicts was the engine and the problem with the engine was not check deps per build, I did both so there are no other objections. At least I didn't see any, so i wasn't ignoring anything for the other conversations. --- Justin F. Hallett Blue Falls Manufacturing Ltd. I.T. Manager/Marketing http://www.goarctic.com Tel: (780) 789-2626 Fax: (780) 789-2624 On 4-Dec-03, at 3:26 PM, Max Horn wrote: BTW, changing some fundamental behavior of fink w/o *any* discussion, or at least announcement of that change, on fink-devel, is *really* bad. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
Well i don't see this as true, it's well commented and I've read threw it a few times, and I'd likely jump into it someday I just think a few more things where more important and needed dealing with first. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 4-Dec-03, at 3:26 PM, Max Horn wrote: I did (putting in the fink cleanup code incomplete, in the hopes that somebody else will fix it). smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
On Dec 4, 2003, at 1:36 PM, TheSin wrote: Already stated I will no longer work be working on fink's code base unless it's to fix something that I created. Sorry to try and advance fink instead of complaining yet again about something that has been discuss a dozen times already. Aw cmon don't be immature about it, its all about communication. Of course everyone appreciates the contributions and we want you to contribute more. I have two branches already they don't work, they have been there for over 6 months, no one tests them and no one merges/updates them. You need to kick people to get them to help out and remind people of things, i dont remember even what other branches you have. I'd test your BC branch. -Ben --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly field
Am Dienstag, 02.12.03 um 23:45 Uhr schrieb TheSin: up until recently BuildDependsOnly was an accepted field but it didn't do anything. Dave has added a warning if a pkgs depends on a BuildDependsOnly pkg now. And I just added to fink cvs two more functions that now use BuildDependsOnly. those being fink list -b or fink list -b -i to see which you have installed and fink remove|purge -b or -b list. I'd just like to take this time to get all Maintainers to check there pkgs and make sure they have this field in proper pkgs, mostly -dev pkgs. I might self know I have some pkgs missing it, ie test-simple-pm and test-hardness-pm and I'm sure many others. I'm going to be adding proper checking the validator for this field shortly. How exactly could the validator do this? I.e. what exactly do you want to validate, and how? Do you want to check the dependencies of all packages for illegal deps, or what? Also on a side note I'm working on fink remove -d pkg which will remove a pkg and all it's deps, this will need some what of a new dep engine, and I'll be able to make a fink deptree pkg using the same engine, are there any suggestions/requests before I start this? I think doing this properly is a very hard task. Are you sure you're up to it? For now, it might be *much* simpler to simply change fink remove to use apt-get remove instead of dpkg --remove. That will give you almost exactly the functionality you want w/o having to study graph theory. Max --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly field
I thought some of you might be interested in the wrapper I've been using for Fink lately. It requires Fink packages expect-pm and debfoster-2.5 . Here's what the wrapper `bfink` does to modify the build process: bfink Description: Binary data rmorphans2 Description: Binary data 1. Becomes root with 'sudo -H', so that ccache doesn't ignore my max-disk-usage settings and dump root-owned files in ~/.ccache . 2. Adds any newly installed packages to my keepers, and removes any newly removed packages from my keepers. 3. Calls the utility program rmorphans2 to remove all the packages that were only installed as a [Build]Depend, but that I don't want kept. Items two and three allow me to say 'bfink install xmms' and have fink install all the deps and builddeps, build xmms, and then remove all the builddeps. I can also do 'bfink remove xmms', and all the deps will be removed too. Saves lots of disk space, and time too, since an 'update-all' no longer updates all kinds of packages which are lying around but I don't need. Obviously the ugly techniques I use aren't the way Fink should do things. This is just a pointer to one of the good ways a knowledge of the dep tree could be used inside Fink. I'd within fink. Toodles, vasi PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
On Tue, Dec 02, 2003 at 03:45:54PM -0700, TheSin wrote: Also on a side note I'm working on fink remove -d pkg which will remove a pkg and all it's deps, this will need some what of a new dep engine, and I'll be able to make a fink deptree pkg using the same engine, are there any suggestions/requests before I start this? A bunch of months ago there was a brief discussion about fink maintaining a database of packages that were explicitly installed (cf. those that were only installed due to dependencies of them), with maybe an eye towards automatically removing those that were automatically installed when they were no longer needed. It's probably in the -devel archives...somewhere. Also related might be Feature Requests tracker #496468. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
libfinch (Was: Re: [Fink-devel] BuildDependsOnly field)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 02, 2003, at 17:45, TheSin wrote: Also on a side note I'm working on fink remove -d pkg which will remove a pkg and all it's deps, this will need some what of a new dep engine, and I'll be able to make a fink deptree pkg using the same engine, are there any suggestions/requests before I start this? I have started a project to replace the Fink dep engine with a more generic one, called libfinch, and have already begun a perl interface to my library. I am developing the project on SourceForge at http://www.sourceforge.net/projects/libfinch. I currently do not have much time for this project, but I am planning to work on it for a Senior Technology Project next year, and I will have much more time then. There is a new set of packages on the package submission tracker, ID 843416, that provide generic version management, with interfaces in Obj-C, C, and Perl. The libraries must be installed with libibrary first, libfinch second, and Finch (Perlmod) third. All assistance is welcome, just email me privately if you want to help. At http://www.tjhsst.edu/~kmoffett/Services.pm.diff is a patch to a (somewhat) recent CVS Services.pm which replaces the version comparison with my faster libfinch (C) library. It isn't much, but I am working on adding version ranges, version sets, and associative version sets which allow the creation of arbitrary groups of versions. The associative sets allowing the association of arbitrary Objective-C (and later Perl) objects to any subset of versions. P.S.: If somebody with CVS access could look at the packages for me, I'd really appreciate it, I posted updates several days ago but haven't had a response yet. Cheers, Kyle Moffett -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/zS7Dag7LSGnFq10RAjZXAJ9AgOE/sLmL2YXGslwxhgYcgjPL7ACghOup FSCgNvqPQfGqiIHY7LIGcJg= =dBdc -END PGP SIGNATURE- --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly field
yes to a degree but backwards, compile a list of pkgs that have build only deps and search for depends on em, but only if your checking the whole tree. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 2-Dec-03, at 4:23 PM, Max Horn wrote: How exactly could the validator do this? I.e. what exactly do you want to validate, and how? Do you want to check the dependencies of all packages for illegal deps, or what? smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
I'm just gonna do it steps, first I need BuildConflicts, which I just added, now I'm gonna add the transparent check before every build code, it'll remove and install as needed but won't ask since the first summary will cover it all anyhow. And I've got that part almost working already, but I need to make small commits in between to not confuse myself, and so other can't help find any problems if there are any in little burst as so I don't get too far ahead, but this stuff has been put off too long, and been complained about too much. So instead of my complaining about it again I just decided to do it. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 2-Dec-03, at 4:23 PM, Max Horn wrote: I think doing this properly is a very hard task. Are you sure you're up to it? For now, it might be *much* simpler to simply change fink remove to use apt-get remove instead of dpkg --remove. That will give you almost exactly the functionality you want w/o having to study graph theory. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
I've already addressed this to a degree, see fink list -i -b and fink remove|purge -b --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 2-Dec-03, at 4:29 PM, Dave Vasilevsky wrote: Items two and three allow me to say 'bfink install xmms' and have fink install all the deps and builddeps, build xmms, and then remove all the builddeps. I can also do 'bfink remove xmms', and all the deps will be removed too. Saves lots of disk space, and time too, since an 'update-all' no longer updates all kinds of packages which are lying around but I don't need. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: libfinch (Was: Re: [Fink-devel] BuildDependsOnly field)
I'd love to start in this but I only know perl, and even that, well you read Max's comment I'm sure he is trembling now that I decided to take this on, I just hope that you can just convert my perl additions for libfinch easily, that is the best I can do for help...sorry --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 2-Dec-03, at 5:30 PM, Kyle Moffett wrote: I have started a project to replace the Fink dep engine with a more generic one, called libfinch, and have already begun a perl interface to my library. I am developing the project on SourceForge at http://www.sourceforge.net/projects/libfinch. I currently do not have much time for this project, but I am planning to work on it for a Senior Technology Project next year, and I will have much more time then. There is a new set of packages on the package submission tracker, ID 843416, that provide generic version management, with interfaces in Obj-C, C, and Perl. The libraries must be installed with libibrary first, libfinch second, and Finch (Perlmod) third. All assistance is welcome, just email me privately if you want to help. At http://www.tjhsst.edu/~kmoffett/Services.pm.diff is a patch to a (somewhat) recent CVS Services.pm which replaces the version comparison with my faster libfinch (C) library. It isn't much, but I am working on adding version ranges, version sets, and associative version sets which allow the creation of arbitrary groups of versions. The associative sets allowing the association of arbitrary Objective-C (and later Perl) objects to any subset of versions. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] BuildDependsOnly field
On Dec 2, 2003, at 3:29 PM, Dave Vasilevsky wrote: 3. Calls the utility program rmorphans2 to remove all the packages that were only installed as a [Build]Depend, but that I don't want kept. This would be a really nice feature to have implemented directly in fink. -Ben --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly field
it is good to work in CVS. But for major dep engine changes you might want to work in a 'branch' instead, not HEAD. -Ben On Dec 2, 2003, at 7:22 PM, TheSin wrote: I'm just gonna do it steps, first I need BuildConflicts, which I just added, now I'm gonna add the transparent check before every build code, it'll remove and install as needed but won't ask since the first summary will cover it all anyhow. And I've got that part almost working already, but I need to make small commits in between to not confuse myself, and so other can't help find any problems if there are any in little burst as so I don't get too far ahead, but this stuff has been put off too long, and been complained about too much. So instead of my complaining about it again I just decided to do it. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 2-Dec-03, at 4:23 PM, Max Horn wrote: I think doing this properly is a very hard task. Are you sure you're up to it? For now, it might be *much* simpler to simply change fink remove to use apt-get remove instead of dpkg --remove. That will give you almost exactly the functionality you want w/o having to study graph theory. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
