felix winkelmann <bunny...@gmail.com> writes: > On Sat, Apr 11, 2009 at 4:34 AM, Aleksej Saushev <a...@inbox.ru> wrote: >> >> 2. Unsupported stable branch. >> >> Meanwhile Chicken development continues and it's going to enter >> pre-release state. From the development list I learn that 4.0.0 >> is really a major milestone, it does change things significantly >> and all auxilliary software (which is of primary importance to me) >> has to be _ported_. When asked about support plans for branch "3", >> maintainer answers that there's no interest. I have to assume that >> support is mostly discontinued(?). > > Progress has to be made and the module system is a major > quantum leap that was direly necessary if all that auxilliary software > is still supposed to work in a few years when all those eggs will > get into serious name-conflicts (we already have them). I would also > like to point out that the eggs and the infrastructure to provide them > to users is fully working and will be kept that way for an undetermined > but lengthy time. And after all I think we do a pretty good job even > if something breaks from time to time. A wc on the svn repo should > demonstrate that, for the amount of code in there, we could do > worse.
There's one serious problem with this: there's no easy way to get specific egg version that is known to work. And there's no way to get it with "chicken-setup" tool. Since this is new feature for 3.4 series, it is unlikely to appear. > The porting effort for most eggs will be trivial. Some eggs make no > sense with chicken4 ("modules", etc.) and some eggs are not worth > porting. The new installation tools have been rewritten largely to > make it easier for users to work with egg tree snapshots and so > achieve more stability, even in the presence of continuing maintenance. I don't know what is "egg tree snapshot", but I have some doubts that it is good decision to require users to have the whole source tree locally. I may be wrong here, since I don't know what you mean exactly. >> 4. What is it? What can I do with it?? >> >> Target systems reside in separate network, there's no access to Internet, >> unless I setup connection via GSM modem. Thus I need to fetch all >> necessary files, bring them there, copy them on target systems and install. >> Obvious. Not so obvious, when you're doing it. >> >> First, you don't have recursive fetch. Workaround: install all what you >> need on development system, list extensions, _guess_ corresponding eggs' >> names, fetch those, bring them on the scene, and... get busted. >> You cannot pass neither distributed file name nor name of directory with >> downloaded files to "chicken-setup" tool. It simply doesn't support it. > > The format of the .meta files in the repository practically screams out > for automatic processing. You could take an egg-tree and easily collect > all necessary information to roll your own deployment infrastructure. > Yes, you'll have to write it yourself, but you can not expect us to > take care of every possible deployment scenario. This is a subject > of ongoing research and we will improve the system as much as > we can. In the moment simplicity is (IMHO) the most important thing, > because it makes it easier for users to write their own custom > deployment code. The biggest problem is the inability to use chicken-setup as pkg_add, while this shouldn't be such a problem to implement on your side. I hope this will be fixed in future in some way. >> 5. Where's it??? >> >> I haven't run into this problem yet, but where's download cache or how >> can I turn it on? > > Chicken 3 has no download cache. "chicken-setup" is not a full package > manager like "dpkg" and people should not expect it to be one. > Chicken-4 hasn't one either but can be used to provide something > comparable. Alternatively we can cram the egg-tools full of features that > fit nobody perfectly and are eternally bug-ridden. Well, there're some essential features, like "fetch" and "add/install", it is sufficient to expose them in a more convenient way. >> 6. Versioning, versioning... >> >> Previously I thought that having version number in file name is very >> useful, since it is really convenient. I was mistaken. Experience >> revealed that _not_ having versions is _very_inconvenient_. >> >> Especially when you know that an egg was fixed in last 15 minutes, >> and you're waiting for a new file. > > If you are in a production situation doing this is very, well..., unsmart. > You should take a snapshot of the tree and use version control for this. Check pkgsrc or FreeBSD ports, you don't need version control for it, a set of tarballs is enough. -- BECHA... CKOPO CE3OH... _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users