I was wondering if there would be any benefit to the general community if I made available a debian and ubuntu repository of up to date puppet packages. I have the infrastructure in place anyway for my work (pbuilder + falcon), and can quite easily run up a vhost on a VM somewhere. Debian Etch (4.0) for example has puppet 0.20.1, and will never get a newer version. Ubuntu Feisty has a newer release - 0.22.1, but this still several bug/feature releases behind the current 0.23 release. I can provide infrastructure for repositories for other distros (yum/aptrpm, whatever) too, but I don''t have the time or setup to build packages or manage the infrastructure. Note: I don''t claim ownership of the debian/ubuntu packages mentioned above - I merely took existing ones and upgraded them to newer versions!
On Thu, Jul 12, 2007 at 01:45:27PM +1200, Daniel Lawson wrote:> I was wondering if there would be any benefit to the general community > if I made available a debian and ubuntu repository of up to date puppet > packages. I have the infrastructure in place anyway for my work > (pbuilder + falcon), and can quite easily run up a vhost on a VM somewhere. > > Debian Etch (4.0) for example has puppet 0.20.1, and will never get a > newer version. Ubuntu Feisty has a newer release - 0.22.1, but this > still several bug/feature releases behind the current 0.23 release.If you''ve only got a couple of machines, it''s pretty trivial just to download the packages from Debian unstable and install them with dpkg. If you''ve got a lot of Debian machines in your organisation to distribute Puppet updates to you should be running your own local repository you can put the Puppet packages into, because you''ll probably have a bunch of other local packages you need to send around as well. Anyone who adds random repositories off the ''net to the sources.list on real-world, it-needs-to-work systems, needs to have their head read. Even if the repo is secured with keys (to stop injection of random trojaned packages), there''s no way to say "only use packages with these names from this repo", so if the repo operator has a different idea about what the repo is for, or they stuff up, or they go rogue, you can end up with who-the-hell-knows-what packages on your system, because you''ll install whatever is in their repo that''s newer than what came with your distro. Also, if at some point in the future I''m forced to make changes to the packages that makes them no longer compatible with some older releases, then just putting them in a separate repo doesn''t help anyone anyway, because they''ll need to be backported. If you''re offering to do the backports if they''re needed, that''s fine, but it''s orthogonal to providing an apt-compatible repository, and I''m willing to do an awful lot of work to make sure that the Puppet packages still work on at least Sarge and Breezy (which is the minimum supported versions for various clients), so backporting shouldn''t be necessary. - Matt -- Some people are like slinkies. They are fun and don''t actually serve any real purpose, but they still make you smile when you push them down the stairs.
> If you''ve only got a couple of machines, it''s pretty trivial just to > download the packages from Debian unstable and install them with dpkg. If > you''ve got a lot of Debian machines in your organisation to distribute > Puppet updates to you should be running your own local repository you can > put the Puppet packages into, because you''ll probably have a bunch of other > local packages you need to send around as well. >That''s fair enough, but you still need the newer packages. Debian unstable only has 0.22.4 packages available at this point. I''ve seen several discussions on the IRC channel in which people ask if more recent packages are available, and are told to grab the Debian Unstable or Ubuntu Gutsy packages. However, these are no longer the most recent version available, and there is never any indication of when these packages will be updated. No, it''s not terribly difficult for every individual who wants a newer package to upgrade one, but why should everyone have to do this work? Other large well known open source projects build their own packages for precisely this reason - samba is the most obvious example.> Anyone who adds random repositories off the ''net to the sources.list on > real-world, it-needs-to-work systems, needs to have their head read. Even > if the repo is secured with keys (to stop injection of random trojaned >I have no issues with making the entire process as transparent as possible. I was hoping this would be an official repository, and I don''t see why that would be at all problematic from a trust point of view. Luke has said several times he can''t do everything himself, so I''m stepping up and offering assistance.> packages), there''s no way to say "only use packages with these names from > this repo", so if the repo operator has a different idea about what the repo > is for, or they stuff up, or they go rogue, you can end up with > who-the-hell-knows-what packages on your system, because you''ll install > whatever is in their repo that''s newer than what came with your distro. >Not true at all. You can easily pin an entire repo so that nothing from it will install by default - this is the recommended way of using the debian backports repositories, for example. You have to explicitally install packages from the repository in this case. You can also pin based on package name and version, so even if the repository wasn''t organised in a sensible manner [1] you can still selectively control what will when happen when you run "apt-get upgrade". [1] my repo is - I have a "puppet" component which contains the puppet, puppetmaster and facter packages - I could have a separate facter component if that was demanded, but it makes a lot of sense to have facter in with puppet> Also, if at some point in the future I''m forced to make changes to the > packages that makes them no longer compatible with some older releases, then > just putting them in a separate repo doesn''t help anyone anyway, because > they''ll need to be backported. If you''re offering to do the backports if > they''re needed, that''s fine, but it''s orthogonal to providing an > apt-compatible repository, and I''m willing to do an awful lot of work to > make sure that the Puppet packages still work on at least Sarge and Breezy > (which is the minimum supported versions for various clients), so > backporting shouldn''t be necessary. >I''m not quite sure of your angle here. Are you saying you are the puppet package maintainer for Debian or Ubuntu, or that you are in some way the official (project-official) puppet package maintainer? I''m definitely not meaning to step on anyones toes regarding this. It''s also no skin off my nose if Luke doesn''t want to run a repo, but if no one steps up and suggests it, it might get passed by just because no one stepped up and suggested it. :)
Daniel Lawson <daniel@meta.net.nz> writes:> Debian Etch (4.0) for example has puppet 0.20.1, and will never get a > newer version. Ubuntu Feisty has a newer release - 0.22.1, but this > still several bug/feature releases behind the current 0.23 release.For Debian etch, please instead upload packages to backports.org if you want to make available the backported packages (not that they require any real backporting) and if they''ll accept them. That way, people can use them without adding yet another repository. Many people running Debian stable already pull selected packages from backports. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Thu, Jul 12, 2007 at 03:14:16PM +1200, Daniel Lawson wrote:> > > If you''ve only got a couple of machines, it''s pretty trivial just to > > download the packages from Debian unstable and install them with dpkg. If > > you''ve got a lot of Debian machines in your organisation to distribute > > Puppet updates to you should be running your own local repository you can > > put the Puppet packages into, because you''ll probably have a bunch of other > > local packages you need to send around as well. > > That''s fair enough, but you still need the newer packages. Debian > unstable only has 0.22.4 packages available at this point.An excerpt from http://ftp.debian.org/pool/main/p/puppet/: puppet_0.23.0-1_all.deb 10-Jul-2007 16:17 I originally uploaded on 25 June but the incoming queue ate the upload. I think I forgot to sign the .changes before I uploaded it.> I''ve seen several discussions on the IRC channel in which people ask if > more recent packages are available, and are told to grab the Debian > Unstable or Ubuntu Gutsy packages. However, these are no longer the most > recent version available, and there is never any indication of when these > packages will be updated. No, it''s not terribly difficult for every > individual who wants a newer package to upgrade one, but why should > everyone have to do this work?They shouldn''t, that''s why I get a new package ready immediately after a new release. Yep, I fucked up this time around. Whoops. Bug reports against Debian packages should be made in the Debian BTS, as always.> > packages), there''s no way to say "only use packages with these names from > > this repo", so if the repo operator has a different idea about what the repo > > is for, or they stuff up, or they go rogue, you can end up with > > who-the-hell-knows-what packages on your system, because you''ll install > > whatever is in their repo that''s newer than what came with your distro. > > Not true at all. You can easily pin an entire repo so that nothing from > it will install by default - this is the recommended way of using the > debian backports repositories, for example. You have to explicitally > install packages from the repository in this case.Which is *entirely* different from what I was referring to, and requires you to run apt-get -t <repo> install puppet on every machine by hand. Pinning your Puppet repo makes it impossible to upgrade Puppet from within Puppet, as well. I''m quite familiar with pinning, thank you very much, and that is why I phrased what I wrote in exactly the manner I did.> You can also pin > based on package name and version, so even if the repository wasn''t > organised in a sensible manner [1] you can still selectively control > what will when happen when you run "apt-get upgrade".Then you have to rearrange your pins on every machine every time a new release comes out. That''s even *worse* than NotAutomatic: yes or pinning the repo.> > Also, if at some point in the future I''m forced to make changes to the > > packages that makes them no longer compatible with some older releases, then > > just putting them in a separate repo doesn''t help anyone anyway, because > > they''ll need to be backported. If you''re offering to do the backports if > > they''re needed, that''s fine, but it''s orthogonal to providing an > > apt-compatible repository, and I''m willing to do an awful lot of work to > > make sure that the Puppet packages still work on at least Sarge and Breezy > > (which is the minimum supported versions for various clients), so > > backporting shouldn''t be necessary. > > I''m not quite sure of your angle here. Are you saying you are the puppet > package maintainer for Debian or Ubuntu, or that you are in some way the > official (project-official) puppet package maintainer?I''m both project-official Debian guy and maintainer of Puppet for Debian. - Matt -- "Mr... Baggins. It seems you have been leading... two lives. In one... you are an ordinary hobbit... you organize your uncle''s diary... give generous gifts to children. In the other... you are the Ring Bearer... charged to carry the One Ring to Mount Doom. One life has... a future, Mr... Baggins, and the other..."
Daniel Lawson <daniel@meta.net.nz> writes:> That''s fair enough, but you still need the newer packages. Debian > unstable only has 0.22.4 packages available at this point.0.23 isn''t exactly old. However, if the folks currently doing Puppet packaging for Debian ever need/want any more hands, I''m also a Debian Developer and am happy to help update packages to a new release and maintain the same backward compatibility as the existing packages if they need someone else to fill in when they don''t have cycles. I speak or can learn about any revision control system you care to name, so whatever is currently used, provided that it''s somewhere I can get to, I can work with. The update cycle for the packages in unstable has been fine for us, so this isn''t a complaint in any way. Just volunteering to be another pair of hands as needed. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Wed, Jul 11, 2007 at 09:35:46PM -0700, Russ Allbery wrote:> in when they don''t have cycles. I speak or can learn about any revision > control system you care to name, so whatever is currently used, provided > that it''s somewhere I can get to, I can work with.That sounds like a challenge to me. <grin> For reference, if anyone is interested, the debian/ dir is in a bzr repo at http://www.hezmatt.org/~mpalmer/bzr/puppet.debian . - Matt -- "The day when Hurd is so common that we want to emulate its braindamages is not going to be in my life-time, I suspect." -- Linus Torvalds
Matthew Palmer <mpalmer@hezmatt.org> writes:> On Wed, Jul 11, 2007 at 09:35:46PM -0700, Russ Allbery wrote:>> in when they don''t have cycles. I speak or can learn about any revision >> control system you care to name, so whatever is currently used, provided >> that it''s somewhere I can get to, I can work with.> That sounds like a challenge to me. <grin> For reference, if anyone is > interested, the debian/ dir is in a bzr repo at > http://www.hezmatt.org/~mpalmer/bzr/puppet.debian .bzr isn''t much of a challenge! Manoj made me learn arch! :) Ah, there''s even a README.source file that would have told me that. Well, I think you guys have things under control, honestly, but if you ever need another hand, just let me know. bzr I can easily deal with and publish another branch as needed. I already use bzr to maintain pam-krb5 and pam-afs-session. Want a patch to add LSB init headers to the init scripts (per the recent debian-devel discussion)? -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> An excerpt from http://ftp.debian.org/pool/main/p/puppet/: > > puppet_0.23.0-1_all.deb 10-Jul-2007 16:17 > > I originally uploaded on 25 June but the incoming queue ate the upload. I > think I forgot to sign the .changes before I uploaded it. >OK, it seems packages.debian.org is out of date.>> You can also pin >> based on package name and version, so even if the repository wasn''t >> organised in a sensible manner [1] you can still selectively control >> what will when happen when you run "apt-get upgrade". >> > > Then you have to rearrange your pins on every machine every time a new > release comes out. That''s even *worse* than NotAutomatic: yes or pinning > the repo. >Perhaps so, but given that you already have a tool to do the rearrangement for you... No, I''m kidding.>> I''m not quite sure of your angle here. Are you saying you are the puppet >> package maintainer for Debian or Ubuntu, or that you are in some way the >> official (project-official) puppet package maintainer? >> > > I''m both project-official Debian guy and maintainer of Puppet for Debian. >That isn''t at all obvious. Thanks for clarifying it. As I said, I''m not meaning to tread on anyones toes. As packages.debian.org is out of date; I don''t run any debian unstable servers myself; and I didn''t think of checking the repository directly as you mentioned above, it seemed to me as though the Debian packages were out of date. I merely suggested running an official puppet repository as a way of stopping everyone having to repackage their own upstream releases. As you seem to have this under control, and it is now apparent that Debian Unstable actually *does* have the latest version, my reasons for wanting this have disappeared. I''ve updated the wiki page at http://reductivelabs.com/trac/puppet/wiki/PuppetDebian to reflect this.
On Wed, Jul 11, 2007 at 09:53:38PM -0700, Russ Allbery wrote:> Matthew Palmer <mpalmer@hezmatt.org> writes: > > On Wed, Jul 11, 2007 at 09:35:46PM -0700, Russ Allbery wrote: > > >> in when they don''t have cycles. I speak or can learn about any revision > >> control system you care to name, so whatever is currently used, provided > >> that it''s somewhere I can get to, I can work with. > > > That sounds like a challenge to me. <grin> For reference, if anyone is > > interested, the debian/ dir is in a bzr repo at > > http://www.hezmatt.org/~mpalmer/bzr/puppet.debian . > > bzr isn''t much of a challenge! Manoj made me learn arch! :)Arch was a fantastic development, in that *any* other DRCS looked fantastically simple and elegant in comparison. It has set the UI bar really low, though.> Ah, there''s even a README.source file that would have told me that.I''d even forgotten I put that in there. There ya go.> Want a patch to add LSB init headers to the init scripts (per the recent > debian-devel discussion)?I''ve given up on d-devel -- life is too short. Patches are *always* welcomed, though, regardless of topic. - Matt -- "I have a cat, so I know that when she digs her very sharp claws into my chest or stomach it''s really a sign of affection, but I don''t see any reason for programming languages to show affection with pain." -- Erik Naggum, comp.lang.lisp
On Thu, Jul 12, 2007 at 04:55:35PM +1200, Daniel Lawson wrote:> >> You can also pin > >> based on package name and version, so even if the repository wasn''t > >> organised in a sensible manner [1] you can still selectively control > >> what will when happen when you run "apt-get upgrade". > > > > Then you have to rearrange your pins on every machine every time a new > > release comes out. That''s even *worse* than NotAutomatic: yes or pinning > > the repo. > > Perhaps so, but given that you already have a tool to do the > rearrangement for you... No, I''m kidding.Thank ghods for that. The pinning format almost seems specifically designed to resist automated editing.> >> I''m not quite sure of your angle here. Are you saying you are the puppet > >> package maintainer for Debian or Ubuntu, or that you are in some way the > >> official (project-official) puppet package maintainer? > > > > I''m both project-official Debian guy and maintainer of Puppet for Debian. > > That isn''t at all obvious. Thanks for clarifying it.Out of interest, what would be some ways to make this more clear? The only thing I can think of is to switch the Maintainer field to me, but do people look at the Maintainer field? I do turn up in the second hit for "Puppet Debian" in Google...> packages.debian.org is out of date; I don''t run any debian unstablepackages.qa.debian.org is better than p.d.o; the latter doesn''t get updated very often, and p.qa.d.o has a lot more useful information. Would it be generally helpful if I reported all Puppet package uploads on this list (or others)? I just figured that anyone interested in new Debian uploads would be watching the package tracking system, and I didn''t think the list needed the noise. I''ll announce it here if people think it''d be useful, though. - Matt -- For instance "Mine eyes haves seen the glory of the coming of the Lord," the anthem of the abolitionists (and the Union forces in the civil war) doesn''t actually refer to theology but the superiority of Arch over CVS. -- Jaldhar H. Vyas, debian-devel
> An excerpt from http://ftp.debian.org/pool/main/p/puppet/: > > puppet_0.23.0-1_all.deb 10-Jul-2007 16:17 > > I originally uploaded on 25 June but the incoming queue ate the upload. I > think I forgot to sign the .changes before I uploaded it. > >i would not install 0.23.0 if i were you. I tried it and it broke all my crons and reasted badly to my shorewall recipe so you should wait that Luke put the next version before using anything newer than 0.22.4 :) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
>> That isn''t at all obvious. Thanks for clarifying it. >> > > Out of interest, what would be some ways to make this more clear? The only > thing I can think of is to switch the Maintainer field to me, but do people > look at the Maintainer field? I do turn up in the second hit for "Puppet > Debian" in Google... >I did look at the maintainer field while responding to you earlier, actually, which added to the confusion a bit. I''m not that familiar with the internal politics of debian package management, but it seems to me that if you''re the one actually maintaining the package, your name should be there... ?> packages.qa.debian.org is better than p.d.o; the latter doesn''t get updated > very often, and p.qa.d.o has a lot more useful information. >Well, that''s a useful bit of information too :)> Would it be generally helpful if I reported all Puppet package uploads on > this list (or others)? I just figured that anyone interested in new Debian > uploads would be watching the package tracking system, and I didn''t think > the list needed the noise. I''ll announce it here if people think it''d be > useful, though. >Having up to date information on the PuppetDebian page is probably good enough, and the more people that know about it the less of a problem it will be. Maybe having some comment somewhere that there are active debian developers pushing new packages into debian unstable as relevant would also be good. One other thing I noticed is that the PuppetDebian wiki page has a link for the "stable" release of Debian, which points to p.d.o, and then another link for "unstable" which actually points to DebianUnstablePackages, however it looks identical to the first link. I''m used to internal wiki links being written out in CamelCase (thank you phpwiki for that), so didn''t actually notice that DebianUnstablePackages existed until I edited PuppetDebian to reflect the 0.23 packages available. Not sure about the best way to tackle that - is there a style guide for the wiki we should try to adhere to? :)
On Thu, Jul 12, 2007 at 06:25:38PM +1200, Daniel Lawson wrote:> >> That isn''t at all obvious. Thanks for clarifying it. > > > > Out of interest, what would be some ways to make this more clear? The only > > thing I can think of is to switch the Maintainer field to me, but do people > > look at the Maintainer field? I do turn up in the second hit for "Puppet > > Debian" in Google... > > I did look at the maintainer field while responding to you earlier, > actually, which added to the confusion a bit. I''m not that familiar > with the internal politics of debian package management, but it seems to > me that if you''re the one actually maintaining the package, your name > should be there... ?It''s a historical artifact, caused by Jamie starting the packaging then handing it to me, with the intention of us both maintaining the package together. Then Jamie''s situation changed, and he hasn''t had much to do with the packaging since the initial work. I''ve never felt the need to change it. Debian packages have a separate "Uploaders" field, which lists everyone involved in the packaging, which you should usually use in preference to the Maintainer field if available, because the Maintainer can only have one entry, and more and more Debian packages have teams maintaining them. I''ve switched the maintainer around, with Jamie''s permission.> > Would it be generally helpful if I reported all Puppet package uploads on > > this list (or others)? I just figured that anyone interested in new Debian > > uploads would be watching the package tracking system, and I didn''t think > > the list needed the noise. I''ll announce it here if people think it''d be > > useful, though. > > Having up to date information on the PuppetDebian page is probably good > enough, and the more people that know about it the less of a problem it > will be. Maybe having some comment somewhere that there are active > debian developers pushing new packages into debian unstable as relevant > would also be good.I''ve added more info to the PuppetDebian wiki page to that effect, and linked to p.qa.d.o more prominently.> One other thing I noticed is that the PuppetDebian wiki page has a link > for the "stable" release of Debian, which points to p.d.o, and then > another link for "unstable" which actually points to > DebianUnstablePackages, however it looks identical to the first link. > I''m used to internal wiki links being written out in CamelCase (thank > you phpwiki for that), so didn''t actually notice that > DebianUnstablePackages existed until I edited PuppetDebian to reflect > the 0.23 packages available. Not sure about the best way to tackle that > - is there a style guide for the wiki we should try to adhere to? :)No, unfortunately. The whole CamelCase vs noncamelcase debate is a harsh one, and it''s not helped on the Puppet wiki with the fight between Trac wiki syntax and reStructuredText. - Matt -- Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen. -- John Steinbeck
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 July 2007, Russ Allbery wrote:> Daniel Lawson <daniel@meta.net.nz> writes: > > Debian Etch (4.0) for example has puppet 0.20.1, and will never get a > > newer version. Ubuntu Feisty has a newer release - 0.22.1, but this > > still several bug/feature releases behind the current 0.23 release. > > For Debian etch, please instead upload packages to backports.org if you > want to make available the backported packages (not that they require any > real backporting) and if they''ll accept them. That way, people can use > them without adding yet another repository. Many people running Debian > stable already pull selected packages from backports.Indeed, Matthew, uploading the packages to backports would be really cool[1]. Regards, David [1] "cool" in the sense of "save some work by integrating with infrastructure and trust paths already in place" ;) - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGld2H/Pp1N6Uzh0URAuNtAJ4h6Dz1QffzVlQU9JIv59O3GgOfMACgkD9E 1Qi46WloX/wrZSs/lm43pzI=/hpE -----END PGP SIGNATURE-----
On Thu, Jul 12, 2007 at 09:51:32AM +0200, David Schmitt wrote:> On Thursday 12 July 2007, Russ Allbery wrote: > > Daniel Lawson <daniel@meta.net.nz> writes: > > > Debian Etch (4.0) for example has puppet 0.20.1, and will never get a > > > newer version. Ubuntu Feisty has a newer release - 0.22.1, but this > > > still several bug/feature releases behind the current 0.23 release. > > > > For Debian etch, please instead upload packages to backports.org if you > > want to make available the backported packages (not that they require any > > real backporting) and if they''ll accept them. That way, people can use > > them without adding yet another repository. Many people running Debian > > stable already pull selected packages from backports. > > Indeed, Matthew, uploading the packages to backports would be really cool[1].If it ever gets to the point where the Puppet binary packages as provided in unstable won''t work in Etch, I''ll consider it. For now, though, I don''t see the effective difference between using etch-backports and just including unstable at a low priority. - Matt -- (And don''t even mention the Army Of Cultists that pop up every time you claim that it might be less than absolutely perfect for every purpose ever conceived.) -- Dave Brown, ASR, on MacOS X
--On July 12, 2007 12:46:28 PM +1000 Matthew Palmer <mpalmer@hezmatt.org> wrote:> Anyone who adds random repositories off the ''net to the sources.list on > real-world, it-needs-to-work systems, needs to have their head read. Even > if the repo is secured with keys (to stop injection of random trojaned > packages), there''s no way to say "only use packages with these names from > this repo", so if the repo operator has a different idea about what the > repo is for, or they stuff up, or they go rogue, you can end up with > who-the-hell-knows-what packages on your system, because you''ll install > whatever is in their repo that''s newer than what came with your distro.I was pretty sure with aptitude you could pin specific packages to specific repos. I might be wrong.
On Thu, Jul 12, 2007 at 06:08:36AM -0700, Digant C Kasundra wrote:> --On July 12, 2007 12:46:28 PM +1000 Matthew Palmer <mpalmer@hezmatt.org> > wrote: > > > Anyone who adds random repositories off the ''net to the sources.list on > > real-world, it-needs-to-work systems, needs to have their head read. Even > > if the repo is secured with keys (to stop injection of random trojaned > > packages), there''s no way to say "only use packages with these names from > > this repo", so if the repo operator has a different idea about what the > > repo is for, or they stuff up, or they go rogue, you can end up with > > who-the-hell-knows-what packages on your system, because you''ll install > > whatever is in their repo that''s newer than what came with your distro. > > I was pretty sure with aptitude you could pin specific packages to specific > repos. I might be wrong.Google isn''t helping me out in confirming that. Yum seems to have some sort of exclusion logic, though (a real turn up for the books -- a technical innovation from RPM!). If you do find anything along these lines, I''d be interested to hear about it. - Matt -- Another Fine Product From The Nonsense Factory.
On Jul 12, 2007, at 2:19 AM, Matthew Palmer wrote:> No, unfortunately. The whole CamelCase vs noncamelcase debate is a > harsh > one, and it''s not helped on the Puppet wiki with the fight between > Trac wiki > syntax and reStructuredText.Yeah, I wish Trac integrated ReST a bit better (I''m particularly annoyed by search results containing ReST markup instead of rendered text), but I''m not willing to go back to relying on some custom, one- off language. I don''t see a good solution, only a selection of bad ones. -- Most people are born and years later die without really having lived at all. They play it safe and tiptoe through life with no aspiration other than to arrive at death safely. -- Tony Campolo, "Carpe Diem" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Daniel Lawson <daniel@meta.net.nz> writes:> I did look at the maintainer field while responding to you earlier, > actually, which added to the confusion a bit. I''m not that familiar > with the internal politics of debian package management, but it seems to > me that if you''re the one actually maintaining the package, your name > should be there... ?The general rule of thumb for Debian packages is that the last person listed in the Uploaders field is the person actually doing most of the work. :) (The entries tend to accrue in chronological order, so the last person listed is usually the person who''s started the most recently and hence has not gotten distracted and stopped yet.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Matthew Palmer <mpalmer@hezmatt.org> writes:> If it ever gets to the point where the Puppet binary packages as > provided in unstable won''t work in Etch, I''ll consider it. For now, > though, I don''t see the effective difference between using > etch-backports and just including unstable at a low priority.Well, I at least really do not want my systems pulling in packages from unstable even if the package is not otherwise available, which a low priority doesn''t really give me so far as I can tell. backports.org is marked NotAutomatic, which is the behavior I want. We pick which backports we''re going to use site-wide and then distribute a single preferences file to all of our etch systems with the appropriate priorities. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Matthew Palmer <mpalmer@hezmatt.org> writes:> Google isn''t helping me out in confirming that. Yum seems to have some > sort of exclusion logic, though (a real turn up for the books -- a > technical innovation from RPM!). If you do find anything along these > lines, I''d be interested to hear about it.You can pin based on the Origin field in the Release file. For example, this pin prefers packages from my personal repository to anything else: Package: * Pin: release o=rra Pin-Priority: 992 -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 July 2007, Russ Allbery wrote:> Matthew Palmer <mpalmer@hezmatt.org> writes: > > Google isn''t helping me out in confirming that. Yum seems to have some > > sort of exclusion logic, though (a real turn up for the books -- a > > technical innovation from RPM!). If you do find anything along these > > lines, I''d be interested to hear about it. > > You can pin based on the Origin field in the Release file. For example, > this pin prefers packages from my personal repository to anything else: > > Package: * > Pin: release o=rra > Pin-Priority: 992That still doesn''t guard against a malicious repo, which can modify its Release file. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlmOA/Pp1N6Uzh0URAqDSAJ9vTo/p4zyvrohF3wDtbTVfYdRTnwCfXMp+ fdhXP3aFltCv/vhqitQTqCs=gAkm -----END PGP SIGNATURE-----
David Schmitt <david@schmitt.edv-bus.at> writes:> On Thursday 12 July 2007, Russ Allbery wrote:>> You can pin based on the Origin field in the Release file. For >> example, this pin prefers packages from my personal repository to >> anything else:>> Package: * >> Pin: release o=rra >> Pin-Priority: 992> That still doesn''t guard against a malicious repo, which can modify its > Release file.True. apt pinning currently can''t do anything about that. You''re extending some level of trust by listing a repository in your sources. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Thu, Jul 12, 2007 at 09:10:46AM -0700, Russ Allbery wrote:> Matthew Palmer <mpalmer@hezmatt.org> writes: > > > Google isn''t helping me out in confirming that. Yum seems to have some > > sort of exclusion logic, though (a real turn up for the books -- a > > technical innovation from RPM!). If you do find anything along these > > lines, I''d be interested to hear about it. > > You can pin based on the Origin field in the Release file. For example, > this pin prefers packages from my personal repository to anything else: > > Package: * > Pin: release o=rra > Pin-Priority: 992The behaviour I was saying didn''t exist in aptitude or apt-get wasn''t release-level pinning, but rather saying "ignore packages in $repository unless their name matches ^(puppet|puppetmaster)$". Without that, you''re playing pin games (ugh) or leaving yourself open to installing whatever crack the repo maintainer decides to stick in there. - Matt -- Talk about unlucky. D''you know, if I fell in a barrel of tits I''d come out sucking me thumb. -- Seen on the ''net: http://thelawwestofealingbroadway.blogspot.com/2006/01/bang-to-rights.html
Matthew Palmer <mpalmer@hezmatt.org> writes:> On Thu, Jul 12, 2007 at 09:10:46AM -0700, Russ Allbery wrote:>> You can pin based on the Origin field in the Release file. For >> example, this pin prefers packages from my personal repository to >> anything else:>> Package: * >> Pin: release o=rra >> Pin-Priority: 992> The behaviour I was saying didn''t exist in aptitude or apt-get wasn''t > release-level pinning, but rather saying "ignore packages in $repository > unless their name matches ^(puppet|puppetmaster)$". Without that, > you''re playing pin games (ugh) or leaving yourself open to installing > whatever crack the repo maintainer decides to stick in there.Well, pinning does let you do basically that, so I think your objection is more to the syntax of how pins are configured in apt (and also to the fact that you can''t pin by URL or site, only by Release fields). I think most of your concern would be addressed if the preferences file had a better syntax, supported file fragments, and could pin based on URL. It''s not the pinning concept itself that''s broken but how you have to configure it. And with file fragments, I bet some of the syntax problems would even go away. Of course, I''m batting zero for two in getting changes into apt even with attached patches, so I''m not sure if we can get that fixed at all easily. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Thu, Jul 12, 2007 at 09:09:24AM -0700, Russ Allbery wrote:> Matthew Palmer <mpalmer@hezmatt.org> writes: > > If it ever gets to the point where the Puppet binary packages as > > provided in unstable won''t work in Etch, I''ll consider it. For now, > > though, I don''t see the effective difference between using > > etch-backports and just including unstable at a low priority. > > Well, I at least really do not want my systems pulling in packages from > unstable even if the package is not otherwise available, which a low > priority doesn''t really give me so far as I can tell.Pin unstable to priority -1 if you really want "never install from here unless I use -t". According to apt_preferences(5), "How APT Interprets Priorities", "P < 0 prevents the version from being installed". Then, when you use -t, the priority for that distro gets overridden to 990, and everything works.> backports.org is marked NotAutomatic, which is the behavior I want. WeA quick test with a locally configured NotAutomatic:yes repo shows that, if the package only exists in that repo, it will get installed if you ask for it, even without -t. apt-cache policy tells me that it''s recognising the NotAutomatic flag (priority is 1), so I think you need to pin backports by hand if you want the behaviour you think you''re already getting. Of course, with backports you shouldn''t be getting many brand new packages, and even if you were, unless you explicitly *ask* for them they should never turn up. - Matt -- "The day when Hurd is so common that we want to emulate its braindamages is not going to be in my life-time, I suspect." -- Linus Torvalds
Matthew Palmer <mpalmer@hezmatt.org> writes:> On Thu, Jul 12, 2007 at 09:09:24AM -0700, Russ Allbery wrote:>> Well, I at least really do not want my systems pulling in packages from >> unstable even if the package is not otherwise available, which a low >> priority doesn''t really give me so far as I can tell.> Pin unstable to priority -1 if you really want "never install from here > unless I use -t". According to apt_preferences(5), "How APT Interprets > Priorities", "P < 0 prevents the version from being installed". Then, when > you use -t, the priority for that distro gets overridden to 990, and > everything works.Huh, I didn''t realize that was available. Thanks!>> backports.org is marked NotAutomatic, which is the behavior I want. We> A quick test with a locally configured NotAutomatic:yes repo shows that, > if the package only exists in that repo, it will get installed if you > ask for it, even without -t. apt-cache policy tells me that it''s > recognising the NotAutomatic flag (priority is 1), so I think you need > to pin backports by hand if you want the behaviour you think you''re > already getting.Oh, yeah, I was a bit imprecise; I was worried about it pulling in packages due to dependencies that are unsatisfied in stable for some reason (it can happen with broken uploads, particularly to local repositories). I wasn''t as worried about explicitly listing the package on the command line. Although it''s still not a bad idea to do that pin. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Thu, Jul 12, 2007 at 06:17:18PM -0700, Russ Allbery wrote:> Matthew Palmer <mpalmer@hezmatt.org> writes: > > On Thu, Jul 12, 2007 at 09:10:46AM -0700, Russ Allbery wrote: > > >> You can pin based on the Origin field in the Release file. For > >> example, this pin prefers packages from my personal repository to > >> anything else: > > >> Package: * > >> Pin: release o=rra > >> Pin-Priority: 992 > > > The behaviour I was saying didn''t exist in aptitude or apt-get wasn''t > > release-level pinning, but rather saying "ignore packages in $repository > > unless their name matches ^(puppet|puppetmaster)$". Without that, > > you''re playing pin games (ugh) or leaving yourself open to installing > > whatever crack the repo maintainer decides to stick in there. > > Well, pinning does let you do basically that, so I think your objection is > more to the syntax of how pins are configured in apt (and also to the fact > that you can''t pin by URL or site, only by Release fields).That''s exactly my problem -- thanks for actually stating it clearly (a flaw of mine). There''s no actual way to identify a repo in a pin spec that the repo can''t get around.> Of course, I''m batting zero for two in getting changes into apt even with > attached patches, so I''m not sure if we can get that fixed at all easily.Fork! Fork! Spoon! <grin> - Matt -- I wake up to a new world every day -- the one in my boss''s head. -- Mike Andrews, ASR
> That''s exactly my problem -- thanks for actually stating it clearly (a flaw > of mine). There''s no actual way to identify a repo in a pin spec that the > repo can''t get around. >I had a bit more of a look into this, and I have to say I''m completely surprised that the "origin" line you are able to use in a pin doesn''t at all match the "origin" output from apt-cache policy. The man page eventually mentions this, but it''s not really that prominent, and I guess changing this behaviour is "too hard" now.