Re: [gentoo-portage-dev] Re: Problems with the new "no downgrades"
Petteri Räty wrote: Vlastimil Babka kirjoitti: *portage-2.1.5_rc1 (04 Apr 2008) 04 Apr 2008; Zac Medico <[EMAIL PROTECTED]> +portage-2.1.5_rc1.ebuild: 2.1.5_rc1 release. In the event that a previously installed package has since been masked, emerge will no longer perform an automatic downgrade as part of a "world" update. You should either unmask such packages or else explicitly re-merge them in order to have them dowgraded to an unmasked version. Bug #216231 tracks all bugs fixed since 2.1.4.x. Assuming it's because of bug 197810, but that only talks about packages masked by corruption. But is it really so good to apply this also to keyword/package.mask or even ebuild being removed? For example, we had swt-3.3.1.1 in SLOT="3" and released swt-3.4_pre6 with SLOT="3". Later realized it's not backwards compatible enough and released swt-3.4_pre6-r1 in SLOT="3.4" removing the 3.4_pre6 ebuild. So I would expect the slot 3 to downgrade back to 3.3.1.1 (especially if something pulls slot 3 via slot dep). (Note that we can't use slotmove because changing slot in java package means also changing where it's installed and expected.) Now thanks to this change, downgrade won't happen. I think it's not good. VB You can use atoms like OK that solves my problem, thanks. But in general case I think it's still wrong. Package is found to be broken, gets p.masked, but people will keep the masked version and not downgrade. And because it doesn't even warn about that fact, they won't even know! Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] Problems with the new "no downgrades"
*portage-2.1.5_rc1 (04 Apr 2008) 04 Apr 2008; Zac Medico <[EMAIL PROTECTED]> +portage-2.1.5_rc1.ebuild: 2.1.5_rc1 release. In the event that a previously installed package has since been masked, emerge will no longer perform an automatic downgrade as part of a "world" update. You should either unmask such packages or else explicitly re-merge them in order to have them dowgraded to an unmasked version. Bug #216231 tracks all bugs fixed since 2.1.4.x. Assuming it's because of bug 197810, but that only talks about packages masked by corruption. But is it really so good to apply this also to keyword/package.mask or even ebuild being removed? For example, we had swt-3.3.1.1 in SLOT="3" and released swt-3.4_pre6 with SLOT="3". Later realized it's not backwards compatible enough and released swt-3.4_pre6-r1 in SLOT="3.4" removing the 3.4_pre6 ebuild. So I would expect the slot 3 to downgrade back to 3.3.1.1 (especially if something pulls slot 3 via slot dep). (Note that we can't use slotmove because changing slot in java package means also changing where it's installed and expected.) Now thanks to this change, downgrade won't happen. I think it's not good. VB -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] relying on vdb only
Hi, reading comments on bug 209538, I've seen this dangerous thing from Zac: "Once these issues are solved it will be nice if we can rely exclusively on the dependencies from /var/db/pkg." Well, the idea that devs will have to revbump packages just for RDEPEND version restrictions so that portage picks it freaks me :) Then there's: "I do have a tool that copies metadata from ebuilds but I'd prefer to avoid doing anything like that if possible." So maybe it's time to discuss what's possible? :) If that discussion already happens/happened elsewhere, then sorry for noise and please point me there :) Thanks, Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] Does portage store checksums for every installed file in a package?
Amit Dor-Shifer wrote: Hello all, I was wondering whether portage calculates and stores a checksum for every installed file (every file appearing in the output of "equery f "). If so, how can I access it? I've found a Manifest file in distfiles, but it doesn't seem to store checksums for the installed files. Yes it's in /var/db/pkg/$CAT/$PF/CONTENTS - there's md5sum and filesize for each installed file. You can check them for example by qcheck from portage-utils. Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Auto-select slots based on system configuration
Daniel Barkalow wrote: It shouldn't remove the Java VM that java-config is set to. This would be a bit trickier I guess, as every user can have it set differently :) Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Depending on "active" version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: > On a general note, introducing dynamic dependencies into the depgraph > worries me, although I'm not sure I can articulate why. Can you articulate "metadata cache"? :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwJf8tbrAj05h3oQRAgmCAJ4gYozwZqYL8f2Qi3mLx+cE9G4shwCeNnhM +n+IOpU9vuEw7g7xkSLHEi0= =d+dS -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
