Re: packages: java-sun/java-sun.spec - up to 1.6.0.33, sources uploaded via dis...
On Mon, Jul 02, 2012 at 11:38:25PM +0200, Paweł Gołaszewski wrote: > Proposal: > leave java-sun as 1.6.x line and make brand new package as oracle-java (or > java-oracle). I don't like this – this would suggest one comes from Sun, the other from Oracle, while both are from Oracle now and both were developed mainly by Sun. > Rationale: > there is a lot of places where java 1.6 is still required. And many where > 1.7 has to be used... These must live together, at least on ftp. Yes, that is a reason to keep 1.6 and 1.7 in different packages. As it is often called "Java 6" an "Java 7", then maybe we should package it as 'oracle-java6' and 'oracle-java7'? BTW. we should probably package IcedTea 7 too. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: java-sun/java-sun.spec - up to 1.6.0.33, sources uploaded via dis...
On Mon, 2 Jul 2012, glen wrote: > Author: glen Date: Mon Jul 2 14:39:18 2012 GMT > Module: packages Tag: HEAD > Log message: > - up to 1.6.0.33, sources uploaded via distfiles; > - demos and samples available separately with bsd license, not packaging here > as: > a) should update to 1.7, b) spec should be named java-oracle (or > oracle-java?) Proposal: leave java-sun as 1.6.x line and make brand new package as oracle-java (or java-oracle). Rationale: there is a lot of places where java 1.6 is still required. And many where 1.7 has to be used... These must live together, at least on ftp. -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm)
On Mon, Jul 02, 2012 at 05:01:05PM +0300, Elan Ruusam??e wrote: > and if the upgrade breakage is really serious and detectable, > package could abort upgrade with exit in %prein scriptlet. > rarely used, afaik i saw it somewhere e.g. glibc-preinstall in ALT Linux :) -- WBR, Michael Shigorin -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm)
On 02.07.2012 14:41, Caleb Maclennan wrote: Has the possibility of manually adding some sort of warning flag between certain upgrades been considered? there is warning message that is displayed AFTER upgrade (via %triggerpostun or just %post) :) and if the upgrade breakage is really serious and detectable, package could abort upgrade with exit in %prein scriptlet. rarely used, afaik i saw it somewhere for warning before upgrades: read vcs commits list, pay attention to BIG FAT warnings :) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Cluster stuff (cman, dlm, heartbeat, corosync, openais, pacemaker, drbd, lvm)
2012/7/1 Jacek Konieczny : > On Sun, Jul 01, 2012 at 10:47:19PM +0300, Elan Ruusamäe wrote: >> On 07/01/2012 11:51 AM, Jacek Konieczny wrote: >> > Do we need clvmd in the main lvm2 package? It pulls some dependencies >> > irrelevant for non-clustered setups. >> i'm in for moving clustered deps to subpackages. if it's doable. > > Already done. Theoretically this could break a cluster on upgrade, but > I don't think it would be a mass problem among PLD users ;) And > production clusters are not a thing one upgrades without testing. I have a cluster setup but nobody is going to die if it breaks on an upgrade ;) While I think in a case like this it is probably more important that we have current working packages than that we don't break old ones, I do think this kind of talk happening on the forum highlights the need for some sort of warning channel: If some package upgrade is EXPECTED to break current configurations, poldek should warn and even expect acknowledgement before proceeding with that package. Has the possibility of manually adding some sort of warning flag between certain upgrades been considered? Ideally all upgrades would just work, but with the number of developers and amount of testing we have right now, that is simply not practical. Sometimes we do things that we know will require intervention to work. We need a fool proof way to warn folks before their systems break. Thoughts about where this functionality should be introduced? Caleb ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: lvm2 and initrd
On Mon, 02 Jul 2012, Elan Ruusamäe wrote: > On 07/02/2012 09:22 AM, Jacek Konieczny wrote: > > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusamäe wrote: > >> > anyone interested working that out (so that udev can be again optional > >> > for rootfs on lvm systems)? > > Is udev on initrams that bad, that you just don't want to use it? Are > > there scenarios where udev just won't work? > well, there's continuous fight getting initrd versions of tools > compiled, as new releases tend to get broken with klibc/uclibc/... and > even if they compile with some patching, they can crash in some > configurations/architectures. AFAIR semaphore messages are harmless. > this could end up we will be having glibc version of initrd udev, or no > initrd version of udev at all, because nobody wants to do the porting to > small libc's. Porting, and lately even just static linking, becomes bigger and bigger RPITA, so we may have no choice than to having dynamic linked programs in initrd. I just don't see a reason to justify the extent of work one have to put into making klibc/uclibc/.../static built tools. > and initrd getting bigger and bigger when added more tools into it, so > older kernels (for newer compiled in default is increased, so it *could* > fit) need ramdisk_size commandline override, thus can't be automated > (need manually verified to see that initrd still does fit) It is not the case with initramfs. I have 40MB uncompressed initramfs made by dracut and it boots with our kernel. > so, it's more in to the "liking part" than "udev being bad" I, personally, would abandon our geninitrd in favor of dracut, yes it's large, but it just works, one initrams to boot any system. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
