Re: [CFT] packaging the base system with pkg(8)
On (19/04/2016 13:36), Adrian Chadd wrote: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. > > Because, honestly - fuck it, we've been behind for too long. We need > more mature tools and knowledge with this. > > The irony of course is the people rolling out docker are doing it > after finding that OS packages aren't the best granularity, but > "whatever the package systems in the software stack we're using, and > then tar the whole mess up and distribute it" method. Kinda like > FreeBSD It's close to the way I see the packaging issue.. Our use case may not be the most common one -- we sell software in 2U form factor (hardware included) :) Once in a while one has to roll updates for the base system as well as our firmware. Packages has never been much of a help but rather another obstacle to deal with for me personally and I bet for our support as well. The thing I care about most is to have the same base system for all customers who have installed updates. It's really hard to troubleshoot assuming that some package updates might have failed for a customer. Distributing images comes very handy in this situation. Although packages are useful in development: - Being able to install complete development environment into the base system (debug symbols, compilers). - Installing updates on *dev* machines. Which I'd rather avoid for release builds. By having packages for both release and dev one would need to have release and dev package repositories. Much like stable/unstable repositories in many linux distros. Revision control systems tend to be much better at this at much lower cost. Being able to do 'make happyworld whatever' out of the box on dev machine as well as installing packages built by CI is huge improvement comparing to packaging as it's often done in linux. - Keeping any package metadata up to date in dev is painful (version bump in most cases). How do we intend to do base system package versioning? Is it going to be the same version for all packages or do we intend to bump versions in individual Makefiles? Sorry if it has been discussed already, I must have missed it. IMHO >700 hardly makes any sense. I see no point in having individual package for each binary under /bin and .so. I'd rather tweak a couple Makefiles to remove stuff I don't need. WITH_* options in src.conf could be a great list of packages to start with. Having -doc and -include in separate packages would be appreciated as well. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 08:16:36AM -0500, Andrew Berg wrote: > Also, how much response do you expect in ~17 hours? Developers need time to > sleep, do their day jobs, and formulate a detailed response to a detailed > email. OK, week later -- no any ("interesting", "not interesting", "know issuses", "planed to fix", "expected behavior") response. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, Apr 24, 2016 at 12:14 PM, Daniel Eischen wrote: > On Sun, 24 Apr 2016, Warner Losh wrote: > > On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen >> wrote: >> >> On Sat, 23 Apr 2016, Warner Losh wrote: >>> >>> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >>> wrote: [CC trimmed] > > On Fri, 22 Apr 2016, Warner Losh wrote: > > > I personally will be refraining from engaging further. I plan on seeing >> what gaps there are by adding support to NanoBSD for packages. I'll be >> busy >> with that. In talking to Glen and others, we've already identified a >> few >> easy gaps to fill. Once they've done that, I'll get going on NanoBSD >> with >> the goal to be able to use it to build a bootable system of any >> architecture from packages with no root privs. I expect to find >> issues, >> but >> I don't expect to find any issue that's intractable. I expect after >> the >> issues are resolved, the end product will be better for everybody. >> >> >> Thank you for working on NanoBSD. Do you think it would be possible > to add support for optionally building dump(8) images instead of dd? > > What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? >>> Perhaps I'm missing something, but when last_orders() is called, >>> isn't the disk already unmounted and 'mdconfig -d -u' already >>> run? >>> >> >> >> dump 0f - _.disk.image > ~/foo.dump >> >> worked for me just now. Is there some reason that it wouldn't work for >> you in last orders if you tossed a NANO_DISKIMGDIR in front of it >> and last orders would work for you. You could even pipe it into some >> compression program... >> > > Huh, I didn't know you could do that on the image file. > I feel dumb, now ;-) Don't feel too dumb. If I specify foo.dump as the filename, dump kinda loses its mind when it gets to the end of file. Not sure why. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Mon, Apr 25, 2016 at 10:40:24AM +0800, Alastair Hogge wrote: > Will /usr/src/release/release.sh eventually support building base packages > as an option? Yes. Glen signature.asc Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
Dear FreeBSD community, Thanks so much for this awesome effort. Will /usr/src/release/release.sh eventually support building base packages as an option? If possible, is it something that we could see soon? Ta, Alastair -- Why isn't there a special name for the tops of your feet? -- Lily Tomlin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, 24 Apr 2016, Warner Losh wrote: On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen wrote: On Sat, 23 Apr 2016, Warner Losh wrote: On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: [CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Perhaps I'm missing something, but when last_orders() is called, isn't the disk already unmounted and 'mdconfig -d -u' already run? dump 0f - _.disk.image > ~/foo.dump worked for me just now. Is there some reason that it wouldn't work for you in last orders if you tossed a NANO_DISKIMGDIR in front of it and last orders would work for you. You could even pipe it into some compression program... Huh, I didn't know you could do that on the image file. I feel dumb, now ;-) -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen wrote: > On Sat, 23 Apr 2016, Warner Losh wrote: > > On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >> wrote: >> >> [CC trimmed] >>> >>> On Fri, 22 Apr 2016, Warner Losh wrote: >>> >>> I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. >>> Thank you for working on NanoBSD. Do you think it would be possible >>> to add support for optionally building dump(8) images instead of dd? >>> >> >> >> What do you mean by that, exactly? It would be relatively easy to add >> a step that runs dump on the _.disk.image file and squirrel that away. >> Last orders the code currently calls it, I believe. Is it something as >> simple >> as this, or is there some more complexity that I'm failing to understand >> or grasp? >> > > Perhaps I'm missing something, but when last_orders() is called, > isn't the disk already unmounted and 'mdconfig -d -u' already > run? dump 0f - _.disk.image > ~/foo.dump worked for me just now. Is there some reason that it wouldn't work for you in last orders if you tossed a NANO_DISKIMGDIR in front of it and last orders would work for you. You could even pipe it into some compression program... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
> On Apr 24, 2016, at 05:34, Daniel Eischen wrote: > >> On Sat, 23 Apr 2016, Warner Losh wrote: >> >> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >> wrote: >> >>> [CC trimmed] >>> On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. >>> >>> Thank you for working on NanoBSD. Do you think it would be possible >>> to add support for optionally building dump(8) images instead of dd? >> >> >> What do you mean by that, exactly? It would be relatively easy to add >> a step that runs dump on the _.disk.image file and squirrel that away. >> Last orders the code currently calls it, I believe. Is it something as >> simple >> as this, or is there some more complexity that I'm failing to understand >> or grasp? > > Perhaps I'm missing something, but when last_orders() is called, > isn't the disk already unmounted and 'mdconfig -d -u' already > run? Yup. > -- > DE > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sat, 23 Apr 2016, Warner Losh wrote: On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: [CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Perhaps I'm missing something, but when last_orders() is called, isn't the disk already unmounted and 'mdconfig -d -u' already run? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
This was all it was asked. Thanks. > Im saying that feedback has been heard and understood and providing more > now while things are in flux to try to address those issues is not likely > to be fruitful. > Warner > > Links: > -- > [1] mailto:dan_parte...@rdsor.ro ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: > [CC trimmed] > > On Fri, 22 Apr 2016, Warner Losh wrote: > >> >> I personally will be refraining from engaging further. I plan on seeing >> what gaps there are by adding support to NanoBSD for packages. I'll be >> busy >> with that. In talking to Glen and others, we've already identified a few >> easy gaps to fill. Once they've done that, I'll get going on NanoBSD with >> the goal to be able to use it to build a bootable system of any >> architecture from packages with no root privs. I expect to find issues, >> but >> I don't expect to find any issue that's intractable. I expect after the >> issues are resolved, the end product will be better for everybody. >> > > Thank you for working on NanoBSD. Do you think it would be possible > to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Sat, Apr 23, 2016 at 12:27 AM, Dan Partelly wrote: > You says that everything will be OK. I want to believe you. But giving > the track record VIMAGE has, and how many gugs go on and on with years Im > not so sure that you guys wont do the same with this subsystem, and leave > it with rough edges for half a decade. Because we all know that everything > will be OK in the end. Timeframe is also important. I can't help you with your trust issues. I'm saying that feedback has been heard and understood and providing more now while things are in flux to try to address those issues is not likely to be fruitful. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
To clarify this proposal a bit better, there are only two flags I think should be added to pkg to accommodate the usability issues introduced by base packages and to do so without breaking existing scripts and aliases: -b) only display base packages -B) display both base and third party packages neither -b nor -B) do not display base packages The implementation could be as simple as a regex or as extensive as adding a new field to the database. That aside there's still the issues of versioning and dependencies. Haven't seen many versioning recommendations but given existing implementations (Solaris') have been carefully researched and tested they should be safe and painless to reuse in pkgng. Dependency checking and tracking will likely to be the most time-consuming delta but, IMO and ldd aside, this can be left until 11.1. For 11.0 it should be sufficient to issue a warning to the effect "'pkg remove [anything in base]' is not currently supported and may break parts of the system", at least for those packages which are not already known by their equavilent 'OPTIONS_UNSET' and 'WITHOUT' build params. IMO, Roger Personally I think the behavior of pkg should remain as it now to avoid breaking existing scripts and aliases i.e., base packages would not be shown without specifying a new flag, say '-b'. This base flag could similarly display only base packages and also recognize the leaf concept. Presumably there should also be a flag to display both third party and base packages, especially with the audit flag, but that could be implemented at a future date without significantly reducing the utility of base packages in 11-RELEASE. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
[CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Sorry for hijacking this thread but where can one find the code for 11-CURRENT that handles the packaging of base? I would like to have a look at it so I can form my opinion on packaging base. I moved to FreeBSD from LinuxFromScratch, ( I packaged that with the RPM package manager and it is on Github). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
>> > > *THAT* is the tone I was complaining about. This is not at all respectful. > Respect is a two way street. If you want respect, offer yours. We make our point very poorly, I get you, but it is the result of what you and others from the projectdo. Meaning, 0 communication. I dont know if that means 0 communications skills,or you do not communicate on purpose. You as a member of the core team, should be one of the first to address this problem. After all you the core invested time in code of conducts and other things of questionable value, but at the same time you always avoid to clearly communicate with your user base. > 've met personally with Glen, in person. I had a wonderful chat with him. Maybe you did. We did not. Serious mechanism issues regarding pkg went unanswered on the other list. Look on pkg list, very rational, polite, and to the subject, 100% rational message about pkg base which is not responded. So, you complain about tone, and how helpful would be for ppl to change it. Let me give you a suggestion: start with altering your own behaviour. Offer respect, be communicative, less sensible on internet where it is very hard to convey “tone”. You'll see that it works wonders to indirectly alter the behaviour of the people you so eloquently compared to peasants daring to disturb the lord of the castle. You says that everything will be OK. I want to believe you. But giving the track record VIMAGE has, and how many gugs go on and on with years Im not so sure that you guys wont do the same with this subsystem, and leave it with rough edges for half a decade. Because we all know that everything will be OK in the end. Timeframe is also important. > > >> And I really think THAT is the crux of the argument everyone is trying to >> make. >> >> To reiterate: packages are good. In moderation. As with all other >> things. But they have to solve the general case, and pkg - both the tool >> and the methodology in its current and pending incarnations - does not. >> >> I, and others, are trying to have a real conversation about this. But the >> blowback is incredible. Let alone incredulous. > > > That is understood. Being toxic about it isn't going to help. Being > disrespectful is not going to help. Being hyperbolic isn't going to help. > It isn't a real conversation until that stuff is gone. So far I've seen no > evidence of it being gone. > > I've met personally with Glen, in person. I had a wonderful chat with him. > Based on talking to him, it was clear many of the complaints here were > overblown. Are there rough edges? Yes. Are there things we don't know? Yes. > Is it the end of the world? No. Over the coming weeks, things will get > easier. The rough edges will be sanded off. After talking with him, I have > complete confidence in him and others that are working on making this > happen. I don't need it to be perfect today, because of this confidence. > > I personally will be refraining from engaging further. I plan on seeing > what gaps there are by adding support to NanoBSD for packages. I'll be busy > with that. In talking to Glen and others, we've already identified a few > easy gaps to fill. Once they've done that, I'll get going on NanoBSD with > the goal to be able to use it to build a bootable system of any > architecture from packages with no root privs. I expect to find issues, but > I don't expect to find any issue that's intractable. I expect after the > issues are resolved, the end product will be better for everybody. > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Hi! > This works fine (after a source rebuild of pkg), but for tools like > portupgrade (from ports), which use pkg under the hood to handle > dependency checks. pkg against the ports tree vs. pkg against my > LOCALBASE=/usr/pkg were conflicting. So I asked some questions about how > to resolve this. > The response was bizarre. Wanting to use pkg with a > different directory seemed almost offensive to the people who answered. It was probably the result of estimating the amount of work necessary to implement this. > There was no thought of even considering the use case. I ended up filing > a bugzilla report, but I see that got close with 'works as intended' a > couple of days ago. As usual, if someone complains about some PR being handled ungraceful, would you please, in the name of reason, name the PR, so that others can check the details without searching the open PR pool for it ? > I can't see how pkg as a base package manager would allow me > to continue with my ports->/usr/pkg mapping. If you analyse the code and fix the places where it needs to be adapted, it would probably work. > I really think the biggest problem people have at the moment is the > complete and utter lack of respect core and the pkg crew have for the end > users of the system. Does it help if I explain to you that there is almost no-one there that can listen to your complaints ? Literally ? There are only a small handful of people that work on core or pkg crew, and they work on so many things that they only skim the lists, because of lack of time ? pkg-crew might be 1-2 folks that try to cope with the flood of requests and try to triage according to "can be solved in less time than...". It has nothing to do with lack of respect. > I'm pretty sure we all get WHY this work is being > done. We don't all AGREE with why it's being done. And that is the > conversation we are trying to have. But every time we try to have it, we > get slammed down as a bunch of ungrateful whining non-coders. Sending this email costs me 10mins or so. Committing 1-2 port updates takes the same amount of time. So, what is my choice ? > Lots of people wrote a lot of lines of code for Linux. Is the argument > that we should just adopt that? Because it's written, it must be good? No, that's not the argument the other side is making. They work as much as possible, but there are too few people to work on it. > You guys need to get over that and come back to the table to have a > rational discussion with the vast majority of people who actually USE this > OS. Suggesting that their behaviour is not rational does not help 8-) > All glory to Juniper and Citrix and everyone else who packages the OS > into their various 'appliances'. I use both of the above at work, and > believe me, for the amount of money they take out of my pocket, they can > hire their own release engineers to deal with this internally without > inflicting this on everyone else. Not even they can do that 8-) If I look at the issues citrix has to solve, they probably are spread thin 8-} If I look at the messages a juniper EX switch sends during an upgrade, some of which look strange, their engineering dept. is probably at some limit, too. > To reiterate: packages are good. In moderation. As with all other > things. But they have to solve the general case, and pkg - both the tool > and the methodology in its current and pending incarnations - does not. >From what I learn, pkg in its current form solves *a lot* of problems, and yes, not 100% of all problems. So let's work on the other ones step by step. > I, and others, are trying to have a real conversation about this. But the > blowback is incredible. Let alone incredulous. Thanks for that attempt. We need to find resources (time, skill, code) to have this conversation, and right now, all of that is in very short supply. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Fri, Apr 22, 2016 at 8:41 PM, Lyndon Nerenberg wrote: > You guys need to get over that and come back to the table to have a > rational discussion with the vast majority of people who actually USE this > OS. All glory to Juniper and Citrix and everyone else who packages the OS > into their various 'appliances'. I use both of the above at work, and > believe me, for the amount of money they take out of my pocket, they can > hire their own release engineers to deal with this internally without > inflicting this on everyone else. > *THAT* is the tone I was complaining about. This is not at all respectful. How can we have a rational discussion with people talking about "all glory to" this or that? I don't think it is possible. I get the point you are trying to make, but it is being made so poorly that I have to point that out. You don't get people to come to a table by being disrespectful and demanding their presence. I sit at whatever table I choose to sit at. You have to convince me to sit, not demand that I sit. I haven't responded well to that since the 70's, and I'm ill inclined to start now. Yelling and screaming isn't going to do it. Jumping up and down isn't going to do it. Nobody wants to chat with the mob carrying pitch forks and torches. People do want to talk to rational people having rational discussions perhaps with a point of view that differs from their own. You can scream all you want, but I doubt it will get the results you want. > And I really think THAT is the crux of the argument everyone is trying to > make. > > To reiterate: packages are good. In moderation. As with all other > things. But they have to solve the general case, and pkg - both the tool > and the methodology in its current and pending incarnations - does not. > > I, and others, are trying to have a real conversation about this. But the > blowback is incredible. Let alone incredulous. That is understood. Being toxic about it isn't going to help. Being disrespectful is not going to help. Being hyperbolic isn't going to help. It isn't a real conversation until that stuff is gone. So far I've seen no evidence of it being gone. I've met personally with Glen, in person. I had a wonderful chat with him. Based on talking to him, it was clear many of the complaints here were overblown. Are there rough edges? Yes. Are there things we don't know? Yes. Is it the end of the world? No. Over the coming weeks, things will get easier. The rough edges will be sanded off. After talking with him, I have complete confidence in him and others that are working on making this happen. I don't need it to be perfect today, because of this confidence. I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016, Warner Losh wrote: Sadly the tenor and tone of the discussion isn?t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. I agree. Really, I do! But this must work both ways, and I can say unequivocally that my earlier interactions with the 'pkg' people have been unpleasant. Some time ago I asked about how pkg interacts with LOCALBASE!=/usr/local. This because I like to build ports from /usr/ports, but install them under /usr/pkg so as to keep /usr/local free for truly local code. This works fine (after a source rebuild of pkg), but for tools like portupgrade (from ports), which use pkg under the hood to handle dependency checks. pkg against the ports tree vs. pkg against my LOCALBASE=/usr/pkg were conflicting. So I asked some questions about how to resolve this. The response was bizarre. Wanting to use pkg with a different directory seemed almost offensive to the peoploe who answered. There was no thought of even considering the use case. I ended up filing a bugzilla report, but I see that got close with 'works as intended' a couple of days ago. I can't see how pkg as a base package manager would allow me to continue with my ports->/usr/pkg mapping. I really think the biggest problem people have at the moment is the complete and utter lack of respect core and the pkg crew have for the end users of the system. I'm pretty sure we all get WHY this work is being done. We don't all AGREE with why it's being done. And that is the conversation we are trying to have. But every time we try to have it, we get slammed down as a bunch of ungrateful whining non-coders. Lots of people wrote a lot of lines of code for Linux. Is the argument that we should just adopt that? Because it's written, it must be good? You guys need to get over that and come back to the table to have a rational discussion with the vast majority of people who actually USE this OS. All glory to Juniper and Citrix and everyone else who packages the OS into their various 'appliances'. I use both of the above at work, and believe me, for the amount of money they take out of my pocket, they can hire their own release engineers to deal with this internally without inflicting this on everyone else. And I really think THAT is the crux of the argument everyone is trying to make. To reiterate: packages are good. In moderation. As with all other things. But they have to solve the general case, and pkg - both the tool and the methodology in its current and pending incarnations - does not. I, and others, are trying to have a real conversation about this. But the blowback is incredible. Let alone incredulous. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. True enough. But I am also wary of decending into what became of X, where a build of the xorg metapackage spends 80% of its time running configure, over and over and over again. How long until a source build becomes a series of 'rpmbuild ...' equivalents? Sadly, if this level of fine grained packaging infects the base, it *will* only be a matter of time ... So no matter what the good intentions, this is going to impact everyone, like it or not. --lyndon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Hi! dan wrote: > Another small issue, is in general the politics of the FreeBSD dev team > regarding bug fixes. I personally would be glad to see more commitment from > the dev team regarding bug fixes. >From what I can see, there's not much politics, but serious work overload, and not much room for more commitment. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
As long as packaged base is not mandatory, it is fine by me. +1 on that ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Julian Elischer wrote: I mentioned this before but I think hte answer is to make a change on the way that "meta packages" are displayed by default in pkg. I like this suggestion both as it applies to base and third party packages and agree that the 'leaf' keyword, once documented, will address the use case fairly well. If I install the meta package, I really don't want to see all the sub packages tat are unchanged unless I add '-v'. On the other hand if I upgrade a sub package I want to see that in the context of the metapackage. Similarly if I uninstall of the subpackages. Personally I think the behavior of pkg should remain as it now to avoid breaking existing scripts and aliases i.e., base packages would not be shown without specifying a new flag, say '-b'. This base flag could similarly display only base packages and also recognize the leaf concept. Presumably there should also be a flag to display both third party and base packages, especially with the audit flag, but that could be implemented at a future date without significantly reducing the utility of base packages in 11-RELEASE. Roger ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
It's lack of communication. > *This* is the reason that *this* and similar topics become so heated; > People who are part of a "community", such as FreeBSD. Want to feel > they are part of the "big picture", and immediately feel resentment, It is in fact much more than that. Surely there are such psycho-social effects as you describe, after all we humans are subject to hundred os socio-psycological biases. But there is a much more practical and mundane issue as well: People who use this operating system in their operations have a great stake in it. Such changes affect operations. I welcome change, but at the same time I try to ensure that change goes smoothly. Investing in BSDs by using them in our operation is not a whim, or a decision made drunk under a bridge. It costs us money, time , investment in educating other people to administer those OSEs, continuous education to keep up with change. More than all this, it costs us business reputation when we decide to build an infrastructure for a client on BSDs, and something goes wrong. And I want to keep my customers happy and so far the BSDs delivered this. > when they find they were left out of "big" decisions, like pkg(8). IMO, Its not a problem to be left out of decisions. First, because they are not our decisions to take, and second because I believe decisions are better to be made by small group of persons. What is a problem is the fact that when you discuss those projects and voice your opinions, some label you "anti progress", some " peasant storming a (lord's) castle (with or without a pitchfork,cant remember :P) , others feel that you dont appreciate them and their time, and then they retreat somewhere. You can invalidate the decision made by said group by stoping using the product. Im sure none would care in the unlikely even that I would stop using FreeBSD, but I think they cared when Yahoo stopped using it. Or if they did not, they should have cared :P > People who are part of a "community", such as FreeBSD. Want to feel > they are part of the "big picture", and immediately feel resentment, > when they find they were left out of "big" decisions, like pkg(8). > While the conversation may well have been heated. It would *not* > have meet *quite* as much adamant, persistent resistance. Because > it (pkg) would have been molded into something from the culmination > of the "community'" input. > > This is only from 50 years in the service industry, and the > thousands of mailing lists I've been on, talking here. > > --Chris > >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> p...@freebsd.org | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by >> incompetence. >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016 20:09:30 + "Poul-Henning Kamp" wrote > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. Ahem... *always*? ;-) While I *do* have some opinions on the upcoming pkg-base, as well as the pkg system, itself. I'm playing catch-up with my INBOX. So I will only respond to your remark; I don't ever recall having been asked whether a package system should be implemented, and if so, how it should look. *Prior* to it's having been implemented. Tho it may have come up in the IRC channels. It never reached the mailing lists. *This* is the reason that *this* and similar topics become so heated; People who are part of a "community", such as FreeBSD. Want to feel they are part of the "big picture", and immediately feel resentment, when they find they were left out of "big" decisions, like pkg(8). While the conversation may well have been heated. It would *not* have meet *quite* as much adamant, persistent resistance. Because it (pkg) would have been molded into something from the culmination of the "community'" input. This is only from 50 years in the service industry, and the thousands of mailing lists I've been on, talking here. --Chris > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> > Not taking a side on this discussion, yet… but the first thing that I do not believe there are sides to take, because I am absolutely positive everybody in this thread wants only whats better for FreeBSD, so there is only one side. It is an aspect which in the heat of emotions some people seem to forget. >> The benefits might be worth it in the long run. The benefits are great and they are immediately available upon release of a packaged base. I am all for it . Yet there issue, such as the UI which doesn't handle well big numbers of packages, mechanism issues and convention issues which where raised in another thread and went unanswered by devs so far. Personally my greatest fear is that what happen to VIMAGE wouldn't happen with this great feature. Namely, that it goes in effect with a "good enough" implementation (which may well be a great success for some uses) and then we have to work with the "good enough" implementation for half a decade before it is made bullet proof and orthogonal. Or that UI issues are never solved, claiming that they are "largely cosmetic" anyway. I wouldn't mind waiting 2 point releases for example to become that way, but look, for VIMAGE takes what ... 6 years ? (Nota bene: I do not contest that VIMAGE is great. ) Pople raised valid concerns, devs imvolved in the project seen them, yet those who spearhead the base pkg project did not found appropriate to make a statement to quell ppl fears regarding their commitment to see to all the issues in a pre-determined time frame. I.E a commitment to make it bullet proof by 11.1 as example. Some felt threatened and unappreciated, which is a problem. Both for them and for us, the user. Because the users of this OS are not only the companies who employ the developers, there are thousand of people scattered through the world, ppl who have a great stake invested in this operating system, by the simple fact that they use it everywhere. Another small issue, is in general the politics of the FreeBSD dev team regarding bug fixes. I personally would be glad to see more commitment from the dev team regarding bug fixes. It is kinda disappointing to see known bugs going on and on for years, "good enough" susbsytems having the same fate, and so on. I beleive the team per-ansamble should make a more solid commitment to fix outstanding issues, and try to outline a policy regarding bugs and implementations which lack orthogonality or are only partially completed (even if this partially means 95% ). > occurred to me is that such way of packaging is traditional for the Linux > “distributions”. I could imagine people worrying at subconscious level that > FreeBSD is going the Linux way… and that if they wanted such a model, they > would be using Linux instead. Today, people have more choice in packaging — > but if FreeBSD goes the Linux way, someone else will fill the void — so no > worries in general. > > I can see the support nightmare that a packaged base would bring, but as > always — this is not enough to judge it. The benefits might be worth it in > the long run. > > I was a long time user of BSD/OS and then switched to FreeBSD when that OS > was killed. In BSD/OS everything was monolithic. It was rock stable. Very > dependable and very easy to support. My first few years with FreeBSD were > spent to get used that the OS was not just one piece, but you could end up > with different installs.. A bit more support efforts. Not that I am > complaining :) > > As long as packaged base is not mandatory, it is fine by me. > > Daniel > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> On 19.04.2016 г., at 5:01, Roger Marquis wrote: > > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. > Not taking a side on this discussion, yet… but the first thing that occurred to me is that such way of packaging is traditional for the Linux “distributions”. I could imagine people worrying at subconscious level that FreeBSD is going the Linux way… and that if they wanted such a model, they would be using Linux instead. Today, people have more choice in packaging — but if FreeBSD goes the Linux way, someone else will fill the void — so no worries in general. I can see the support nightmare that a packaged base would bring, but as always — this is not enough to judge it. The benefits might be worth it in the long run. I was a long time user of BSD/OS and then switched to FreeBSD when that OS was killed. In BSD/OS everything was monolithic. It was rock stable. Very dependable and very easy to support. My first few years with FreeBSD were spent to get used that the OS was not just one piece, but you could end up with different installs.. A bit more support efforts. Not that I am complaining :) As long as packaged base is not mandatory, it is fine by me. Daniel ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
This is one of the issue I perceive with using scripts/ intermediate programs as a glue, a problem which does not exist when the daemons are integrated tighter. You basically give up all the power which arises from inter-operating daemons give to the system. It is also the main problem FreeBSD's rc system presents. Because all is a scaffolding of shell scripts, it basically gives you 0 of the power modern service management offer. Most important are service life cycle management, restart policies, delegated administration and fault reporting. The only thing you gain is easy debugability (no small boon)but it is easily outweighted by all other advantages of a modern service manager. > > Well, even if we went this route, this wouldn't quite work, because > the automountd daemon actually doesn't need those notifications. > It's the "-media" map that does. Other parts of autofs don't have > any special code for media handling. About shell scripts in general as a glue: Yes, they are easily debuggable and customized. Yet I believe that all that power should be hidden,and it should be unnecessary to tap into it for 95% of administrative needs. It is my perception that less and less people are interested in exploring the countless ranges of customization such scaffolding of scripts offer. People are interested in sane defaults, easy to specify policies and fault reporting. Life is too short to explore myriad of customizations, unless you really have to. And most of the time, you dont need to. Thats not to say shell scripts dont have their place. They do. I use them too, both on unixes and tcl scripts for adding fast functionality in csico devices. But as a glue between essential operating system subsystems, it is my oppinion that we are 10 years too late in replacing them. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 0422T0908, David Chisnall wrote: > On 21 Apr 2016, at 21:48, Dan Partelly wrote: > > > > Yes, you are right it misses the media change handler in devd.conf. > > maybe it should bementioned somewhere in a man page if it is not > > already there. Thanks for the pointer. > > > > Anyway, if I would have written the system, what I would have done > > is to consolidate both user mode daemons into one and make this > > daemon a client of devd, fstyp a library, and handle all removable > > media inside transparent to the user, without requiring any modifications > > to devd.conf, and without relaying on shell scripts. > > > > Is there any reason you did not took this approach ? This is not > > criticism, I am genuinely interested. > > One of the current shortcomings of devd is that it does not provide a good > mechanism for other running processes to request notification of events > dynamically. Ideally, when the automounter daemon starts, it should connect > to devd via an IPC channel and request notification of the specific events > that it wants. This is a known problem (which extends to more than just the > automounter) and there are some tentative plans to fix it, but they’re not > yet concrete and won’t be in 11.0, though hopefully will appear at some point > in the 11.x series. Well, even if we went this route, this wouldn't quite work, because the automountd daemon actually doesn't need those notifications. It's the "-media" map that does. Other parts of autofs don't have any special code for media handling. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 0421T2348, Dan Partelly wrote: > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. It's mentioned in a comment in auto_master file. But yeah, mentioning it in a manual page seems like a good idea. > Anyway, if I would have written the system, what I would have done > is to consolidate both user mode daemons into one and make this > daemon a client of devd, fstyp a library, and handle all removable > media inside transparent to the user, without requiring any modifications > to devd.conf, and without relaying on shell scripts. > > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. Yes - I actually like shell scripts. I like being able to provide the glue in a way that's easy to debug and modify, without having to rebuild anything, so that it can be tailored to specific needs by the system administrator. In this case the problem, I think, is not with the shell scripting. It's just that it doesn't "enable itself" when needed, or isn't just enabled by default. > > and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > Please consider doing it. A kevent on /media would allow other programs > to see how volumes come and go, and I can imagine several situations > where this can be handy. And too many directories left there do become > annoying. Well, you have devd notifications for this - and it gives you much more flexibility. > > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała wrote: > > > > On 0421T1526, Dan Partelly wrote: > >> The scenario is: > >> > >> Let’s say I have autofs_enable , working with media map. > >> > >> If I have a CD in CD drive , all is well and when the system is fully > >> booted up > >> /media contains a directory through which I can access the content of the > >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > >> /media does not contain a new access point for the new disk inserted in > >> the > >> device. > >> > >> What I would expect is when I change the media in Cd-rom , a new > >> access point for the volume in question should be reated in /media. > >> > >> Perhaps this functionality is exposed differently by the automounter, > >> but them I would not expect the CDrom to be accessible at all though the > >> media map. > > > > If by "access point" you mean the directory, then it will, unless the CD > > doesn't have a label - in that case the device name will be used instead, > > and since it's the same device, it will be the same name - usually "cd0". > > > > However - I've just checked to make sure and it works the way it should. > > What you're decribing seems like you're missing the part of devd.conf(5) > > responsible for notifying autofs about media change. Do you? > > > >>> he problem here is that it's quite hard to fix, there's a risk > >>> of breaking existing functionality, and the problem is largely cosmetic. > >> > >> until you have more than 10 of them there, when it largely annoying. > >> anyway, what is the reason it is very hard to fix and it would break > >> existing > >> functionality. can you please shed some light ? > > > > Basically, the autofs doesn't support removing the nodes. It wasn't > > really required for the usual use case, and it simplified the code a lot. > > Plan was to pick it up again with my next filesystem project, and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > > > [..] > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: devd limitations -- was [CFT] packaging the base system with pkg(8)
> Ideally, when the automounter daemon starts, it should > connect to devd via an IPC channel and request notification of the specific > events that it wants I was under the impression that devd.seqpacket.pipe accomplishes this. Am I right in assuming that the issue is that devd forwards ALL events to a client now, and the limitation is that we cannot specify a filter ? Or there is something else more deep and fundamental ? I am planning to use devd for a inhouse tool. >> though hopefully will appearat some point in the 11.x series. There are a lot of daemons IMO which would benefit from a tighter integration with devd, and abolishment of glue scripts or programs between devd and clients is desirable IMO. Fingers crossed. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 21 Apr 2016, at 21:48, Dan Partelly wrote: > > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. > > Anyway, if I would have written the system, what I would have done > is to consolidate both user mode daemons into one and make this > daemon a client of devd, fstyp a library, and handle all removable > media inside transparent to the user, without requiring any modifications > to devd.conf, and without relaying on shell scripts. > > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. One of the current shortcomings of devd is that it does not provide a good mechanism for other running processes to request notification of events dynamically. Ideally, when the automounter daemon starts, it should connect to devd via an IPC channel and request notification of the specific events that it wants. This is a known problem (which extends to more than just the automounter) and there are some tentative plans to fix it, but they’re not yet concrete and won’t be in 11.0, though hopefully will appear at some point in the 11.x series. David smime.p7s Description: S/MIME cryptographic signature
Re: [CFT] packaging the base system with pkg(8)
Yes, you are right it misses the media change handler in devd.conf. maybe it should bementioned somewhere in a man page if it is not already there. Thanks for the pointer. Anyway, if I would have written the system, what I would have done is to consolidate both user mode daemons into one and make this daemon a client of devd, fstyp a library, and handle all removable media inside transparent to the user, without requiring any modifications to devd.conf, and without relaying on shell scripts. Is there any reason you did not took this approach ? This is not criticism, I am genuinely interested. > and simply > retrofit the changes back to autofs - but that hasn't happened (yet). Please consider doing it. A kevent on /media would allow other programs to see how volumes come and go, and I can imagine several situations where this can be handy. And too many directories left there do become annoying. > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała wrote: > > On 0421T1526, Dan Partelly wrote: >> The scenario is: >> >> Let’s say I have autofs_enable , working with media map. >> >> If I have a CD in CD drive , all is well and when the system is fully booted >> up >> /media contains a directory through which I can access the content of the >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. >> /media does not contain a new access point for the new disk inserted in the >> device. >> >> What I would expect is when I change the media in Cd-rom , a new >> access point for the volume in question should be reated in /media. >> >> Perhaps this functionality is exposed differently by the automounter, >> but them I would not expect the CDrom to be accessible at all though the >> media map. > > If by "access point" you mean the directory, then it will, unless the CD > doesn't have a label - in that case the device name will be used instead, > and since it's the same device, it will be the same name - usually "cd0". > > However - I've just checked to make sure and it works the way it should. > What you're decribing seems like you're missing the part of devd.conf(5) > responsible for notifying autofs about media change. Do you? > >>> he problem here is that it's quite hard to fix, there's a risk >>> of breaking existing functionality, and the problem is largely cosmetic. >> >> until you have more than 10 of them there, when it largely annoying. >> anyway, what is the reason it is very hard to fix and it would break existing >> functionality. can you please shed some light ? > > Basically, the autofs doesn't support removing the nodes. It wasn't > really required for the usual use case, and it simplified the code a lot. > Plan was to pick it up again with my next filesystem project, and simply > retrofit the changes back to autofs - but that hasn't happened (yet). > > [..] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 0421T1526, Dan Partelly wrote: > The scenario is: > > Let’s say I have autofs_enable , working with media map. > > If I have a CD in CD drive , all is well and when the system is fully booted > up > /media contains a directory through which I can access the content of the > CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > /media does not contain a new access point for the new disk inserted in the > device. > > What I would expect is when I change the media in Cd-rom , a new > access point for the volume in question should be reated in /media. > > Perhaps this functionality is exposed differently by the automounter, > but them I would not expect the CDrom to be accessible at all though the > media map. If by "access point" you mean the directory, then it will, unless the CD doesn't have a label - in that case the device name will be used instead, and since it's the same device, it will be the same name - usually "cd0". However - I've just checked to make sure and it works the way it should. What you're decribing seems like you're missing the part of devd.conf(5) responsible for notifying autofs about media change. Do you? > > he problem here is that it's quite hard to fix, there's a risk > > of breaking existing functionality, and the problem is largely cosmetic. > > until you have more than 10 of them there, when it largely annoying. > anyway, what is the reason it is very hard to fix and it would break existing > functionality. can you please shed some light ? Basically, the autofs doesn't support removing the nodes. It wasn't really required for the usual use case, and it simplified the code a lot. Plan was to pick it up again with my next filesystem project, and simply retrofit the changes back to autofs - but that hasn't happened (yet). [..] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
The scenario is: Let’s say I have autofs_enable , working with media map. If I have a CD in CD drive , all is well and when the system is fully booted up /media contains a directory through which I can access the content of the CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. /media does not contain a new access point for the new disk inserted in the device. What I would expect is when I change the media in Cd-rom , a new access point for the volume in question should be reated in /media. Perhaps this functionality is exposed differently by the automounter, but them I would not expect the CDrom to be accessible at all though the media map. > he problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely cosmetic. until you have more than 10 of them there, when it largely annoying. anyway, what is the reason it is very hard to fix and it would break existing functionality. can you please shed some light ? > Huh, never heard about that. I'd expect the existing mechanism to handle > that case just fine. Could you submit a PR? > On 21 Apr 2016, at 12:57, Edward Tomasz Napierała wrote: > > On 0420T1545, dan_partelly wrote: > > [..] > >> Another example is the autofs mounter. The prject was marked as complete >> by FreeBSD foundation in 2014. Last I tried it to autmount removable >> devices, it left directory after directory in the autofs managed directory. >> This is known behavior. > > Yup. The problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely cosmetic. > >> It also did not worked as it should ??? (show it >> manage removable media correctly ) changing CD/DVD media disks. Presumably >> In could have somehow manage it to work by making yet another scaffolding >> of scripts as a questionable glue between devd and automounters. That if >> devd receives media change notifications. I dont know. If not I could patch >> the kernel, yeah. But it is just much to simple to not bother at all and >> use OSx. > > Huh, never heard about that. I'd expect the existing mechanism to handle > that case just fine. Could you submit a PR? > > [..] > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 0420T1545, dan_partelly wrote: [..] > Another example is the autofs mounter. The prject was marked as complete > by FreeBSD foundation in 2014. Last I tried it to autmount removable > devices, it left directory after directory in the autofs managed directory. > This is known behavior. Yup. The problem here is that it's quite hard to fix, there's a risk of breaking existing functionality, and the problem is largely cosmetic. > It also did not worked as it should ??? (show it > manage removable media correctly ) changing CD/DVD media disks. Presumably > In could have somehow manage it to work by making yet another scaffolding > of scripts as a questionable glue between devd and automounters. That if > devd receives media change notifications. I dont know. If not I could patch > the kernel, yeah. But it is just much to simple to not bother at all and > use OSx. Huh, never heard about that. I'd expect the existing mechanism to handle that case just fine. Could you submit a PR? [..] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 11:57:47AM -0400, Paul Mather wrote: > On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote: > > >> A packaged base is just another way of describing the state of the > >> system. People on mailing lists will still be able to help people > >> fix their problems, but they'll just use different information to > >> pinpoint the precise components affected. > > > > How identify this systems? By 800-line lists of package versions? > > > In my experience, troubleshooting usually proceeds from the > description of the symptoms. So, if someone says, "I just updated > and Sendmail has stopped sending e-mails," or "I just updated and I > can no longer SSH into my system," then the logical question is to > ask what versions of the packages they're running that pertain to > those binaries. In other words, you start at the symptom and work > outwards from there. In my experience, it's not necessary to have > an exact inventory of a system to be able to solve a problem with > it. I see you point. Now try this, for some example, semi-hypothetical. Some time ago we have troubles with sshd, fetchmail and other software after r296462. pkg don't show any useful for versions of sshd/fetchmail/etc because root cause will be breakin ABI in libcrypto. For useful information pkg need to show version of quering package and version of all depened packages. Is this allow now by simple command? Also, how to naming individual packages? For port software we have released version, for STABLE -- rollover release. Currently used naming is useless, using svn revision of top-level dir usefull only for two-package case. Using svn revision of individual dirs need addtional patches and addtional rules: /usr/src/sys/modules/aio # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn0.eu.freebsd.org/base/stable/10/sys/modules/aio Relative URL: ^/stable/10/sys/modules/aio Repository Root: svn://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 295564 Node Kind: directory Schedule: normal Last Changed Author: jhb Last Changed Rev: 185878 Last Changed Date: 2008-12-10 23:56:19 +0300 (Wed, 10 Dec 2008) /usr/src/sys/modules/aio # less Makefile # $FreeBSD: stable/10/sys/modules/aio/Makefile 185878 2008-12-10 20:56:19Z jhb $ .PATH: ${.CURDIR}/../../kern KMOD= aio SRCS= vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h EXPORT_SYMS= aio_init_aioinfo aio_aqueue .include i.e. actual revision is max(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h) or even max(deps(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h)) Is this posible? > A tool like pkg makes it easy to know which package is associated > with a given file and also which packages that package depends upon > and which are dependencies of it. So, pkg makes it relatively > painless to zoom in or out from a given symptom (i.e., binary or > library that might have changed). I don't believe this is possible > in the current FreeBSD setup. This is a huge gain in functionality. You are lost may point. I am not against of pkg, I am just try more planing before implementation. Changing in distribution scheme is very expensive. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote: >> A packaged base is just another way of describing the state of the >> system. People on mailing lists will still be able to help people >> fix their problems, but they'll just use different information to >> pinpoint the precise components affected. > > How identify this systems? By 800-line lists of package versions? In my experience, troubleshooting usually proceeds from the description of the symptoms. So, if someone says, "I just updated and Sendmail has stopped sending e-mails," or "I just updated and I can no longer SSH into my system," then the logical question is to ask what versions of the packages they're running that pertain to those binaries. In other words, you start at the symptom and work outwards from there. In my experience, it's not necessary to have an exact inventory of a system to be able to solve a problem with it. A tool like pkg makes it easy to know which package is associated with a given file and also which packages that package depends upon and which are dependencies of it. So, pkg makes it relatively painless to zoom in or out from a given symptom (i.e., binary or library that might have changed). I don't believe this is possible in the current FreeBSD setup. This is a huge gain in functionality. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20 Apr 2016, at 15:53, Paul Mather wrote: > > Arguably, a packaged base will make it easier to help people, because it > makes more explicit the dependencies of different parts of the system. It's > been my experience that the interactions and impact of the various > /etc/src.conf settings are not entirely well known, at least to end-users. In particular, with libxo output from pkg, we can get a machine-readable detailed dump of all of the base system packages installed and provide a single ‘system dump’ command that includes this, relevant information from dmesg, and so on for bug triaging. David smime.p7s Description: S/MIME cryptographic signature
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 10:43:08AM -0400, Paul Mather wrote: > > > Message: 20 > > Date: Wed, 20 Apr 2016 12:48:06 +0300 > > From: Slawa Olhovchenkov > > To: Dan Partelly > > Cc: David Chisnall , Julian Elischer > > , Nathan Whitehorn , > > freebsd-current@freebsd.org > > Subject: Re: [CFT] packaging the base system with pkg(8) > > Message-ID: <20160420094806.gj6...@zxy.spb.ru> > > Content-Type: text/plain; charset=utf-8 > > > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > > > >> IMO, the number of packages per-se is not a problem as long as you > >> can manage them without arcane commands, aliases, pipe - filters, > >> or scripts. (they all have their place, but less , the better) My > >> point is that I don't really want to keep on my head a Unix hacker > >> hat. I (and presumably many other humans ) like simple things,which > >> allow me to type a short command (preferably the whole system should > >> be simple enough to be explained in one-two pages in handbook) , > >> wait for completion, and get on with my life. > > > > Yes and no. > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > Superficially, it does, but in reality it doesn't. I can grab the > source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* > settings in /etc/src.conf and build a kernel and world and end up > with a system that is missing a lot of functionality that is > ordinarily present with an empty /etc/src.conf. That missing > functionality could be the reason for a problem I am having with my > "10.3-RELEASE" system. Identification of custom builds is another problem and now we do this by contens of src.conf, make.conf options and kernel config file. This is enough and I am don't see necessity for change. > That is the reality of FreeBSD *now* and I still am able to get help on > FreeBSD mailing lists when I have problems. > > The case of a moving target is truer of those who choose to run > -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months > from now, what version of the code base am I actually running? > Sure, now we have the SVN revision number to help pinpoint the > version of the code being run (setting aside the effects of > /etc/src.conf), but back in the days when FreeBSD was in CVS we > didn't have that nicety and yet people were still able to get help > with problems running -STABLE or -CURRENT on the mailing lists. With CVS we use timestamp (as for csup). > A packaged base is just another way of describing the state of the > system. People on mailing lists will still be able to help people > fix their problems, but they'll just use different information to > pinpoint the precise components affected. How identify this systems? By 800-line lists of package versions? > Arguably, a packaged base will make it easier to help people, > because it makes more explicit the dependencies of different parts > of the system. It's been my experience that the interactions and > impact of the various /etc/src.conf settings are not entirely well > known, at least to end-users. Some /etc/src.conf settings is compile-time options and can't be done by packages. Kerberos, for example. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> Message: 20 > Date: Wed, 20 Apr 2016 12:48:06 +0300 > From: Slawa Olhovchenkov > To: Dan Partelly > Cc: David Chisnall , Julian Elischer > , Nathan Whitehorn , > freebsd-current@freebsd.org > Subject: Re: [CFT] packaging the base system with pkg(8) > Message-ID: <20160420094806.gj6...@zxy.spb.ru> > Content-Type: text/plain; charset=utf-8 > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > >> IMO, the number of packages per-se is not a problem as long as you >> can manage them without arcane commands, aliases, pipe - filters, >> or scripts. (they all have their place, but less , the better) My >> point is that I don't really want to keep on my head a Unix hacker >> hat. I (and presumably many other humans ) like simple things,which >> allow me to type a short command (preferably the whole system should >> be simple enough to be explained in one-two pages in handbook) , >> wait for completion, and get on with my life. > > Yes and no. > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. Superficially, it does, but in reality it doesn't. I can grab the source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* settings in /etc/src.conf and build a kernel and world and end up with a system that is missing a lot of functionality that is ordinarily present with an empty /etc/src.conf. That missing functionality could be the reason for a problem I am having with my "10.3-RELEASE" system. That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD mailing lists when I have problems. The case of a moving target is truer of those who choose to run -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months from now, what version of the code base am I actually running? Sure, now we have the SVN revision number to help pinpoint the version of the code being run (setting aside the effects of /etc/src.conf), but back in the days when FreeBSD was in CVS we didn't have that nicety and yet people were still able to get help with problems running -STABLE or -CURRENT on the mailing lists. A packaged base is just another way of describing the state of the system. People on mailing lists will still be able to help people fix their problems, but they'll just use different information to pinpoint the precise components affected. Arguably, a packaged base will make it easier to help people, because it makes more explicit the dependencies of different parts of the system. It's been my experience that the interactions and impact of the various /etc/src.conf settings are not entirely well known, at least to end-users. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 2016.04.20 07:58, Lev Serebryakov wrote: It is very worrying to see such reports without any reaction from developers in one month before release. If there is one year till release, it is nothing. But in one month we will have code slush, and after that — release, which should be supported for several years! Also, suggested (and totally ignored in discussion) mechanisms with overlay packages is not UI, it is underlying mechanism which could be very useful. Again, I have nothing against good package management for base. But what I see now is scary, if you take one-month-before-release in account! You mention code slush, but keep saying one month before release. Code slush means *new features* are *discouraged*, not "freeze everything and let it sit for months without addressing any issues". Release is not planned until *September*, and if it is not ready in September, then the release will be delayed. In fact, releases are very frequently delayed since the dates are always estimates and never deadlines. Yes, we are getting somewhat close to release, but there is still time. Also, packaged base work was supposed to be complete enough for wide testing much earlier, but development was stalled for a while. Also, how much response do you expect in ~17 hours? Developers need time to sleep, do their day jobs, and formulate a detailed response to a detailed email. There are certainly issues, but this is not something that is going to be rushed into a release in a month to meet a hard deadline as you imply. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20.04.2016 11:12, David Chisnall wrote: > all of the complaints in this thread have been about the UI, not about the > underlying mechanism. Nope. And there are (small) thread in other mailing list with very big concerns about underlying mechanisms, which doesn't have any attention: https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-April/000183.html It is very worrying to see such reports without any reaction from developers in one month before release. If there is one year till release, it is nothing. But in one month we will have code slush, and after that — release, which should be supported for several years! Also, suggested (and totally ignored in discussion) mechanisms with overlay packages is not UI, it is underlying mechanism which could be very useful. Again, I have nothing against good package management for base. But what I see now is scary, if you take one-month-before-release in account! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
> If these informations were more public I think there will be less > annoyed posts in mailinglist and more constructive critics / ideas / > patches. > And there other issues arising from the lack of communication: How exactly bugs / incomplete features are treated in FreeBSD ? Many times the public gets the impression that save for the show-stopper bugs, or bugs which affect the employers of FreeBSD developers, they don't get too much priority. If any. I talked before about VIMAGE and the bugs surrounding it. Some of those bugs are there for years. Yes VIMAGE was good enough, and as was told before in this thread a success. I am not contesting that. Yet not even today all those bugs and memory leaks are fixed. Patches for some bugs floated around, some where collected some not, only god knows. I heard that now for FreeBSD 11 the FreeBSD foundation forked some money to get it done. I hope they will. Another example is the autofs mounter. The prject was marked as complete by FreeBSD foundation in 2014. Last I tried it to autmount removable devices, it left directory after directory in the autofs managed directory. This is known behavior. It also did not worked as it should ??? (show it manage removable media correctly ) changing CD/DVD media disks. Presumably In could have somehow manage it to work by making yet another scaffolding of scripts as a questionable glue between devd and automounters. That if devd receives media change notifications. I dont know. If not I could patch the kernel, yeah. But it is just much to simple to not bother at all and use OSx. DRM drivers ? Done, but more or less in the same state by years. At least not important in server space. outlining those issues should not make anyone feel criticized. Things are what they are, maybe its better to think what are the root causes of issues like those outlined before. Does the project lacks manpower ? If it does maybe the developers should do something to attract and nurse more and more potential people. Are those issues you dont want to work on or you dont have an agenda to make them bug free and work orthogonal? No problem, make a statement and say .. we wont ever do this , or it will take 6 years ... or whatever. It is not helpful to complain that people do not appreciate your hard work, becuae ppl do. Also not helpful to complain about tones which should be toned down by 2 orders of magnitude, peasants and castles. It is also not helpful to complain that people oppose progress when you are pointed some issues.It couldn't be further removed from truth, at least in my case. But I think most ppl on this list want progress. At least this is my impression. Too much of Unix is badly stuck in the past. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote: > On 04/20/16 10:48, Slawa Olhovchenkov wrote: > > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > > > How do this with many packages? > > Hmmm Good point. > > At release time, a set of packages will be generated. These will all > have the version number of the release eg. 11.0. That's simple and > unambiguous. > > Subsequently adding patches will add a patch level to the version, so > 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel > will cause the output of uname(1) to show the new patch level, but > updates to user land should be reflected in the output of > freebsd-version(1). That's exactly the same as now, and assuming you, > as an end user, install the default set of FreeBSD packages and apply > all the patches as they come out, then there should be no problem. > > This implies that /every/ patchset will include an update to the package > containing freebsd-version. > > What packaging base does do is allow you to be selective in the patches > you apply. So, for instance if patch -p1 was not relevant to you, you > might not install it. So you could end up with a system where you > hadn't installed patches -p1 -- -p9 but you did install patch -p10. The > freebsd-version(1) output would presumably show the system as 11.0-p10 > -- but that's certainly not the same as a system with all of those > patches -p1 to -p9 applied. Or you could just install the updated > freebsd-version(1) package and have your system blatantly lie about its > patching status. This is about RELENG, what about STABLE and CURRENT? > So, yes, this does change the meaning of the version number string. > It's morally equivalent to tracking the releng/11.0 branch in SVN but > compiling your system with various WITH_FOO or WITHOUT_BAR flags, and > possible local modifications to the code base to back out certain > commits. It's still 11.0-SOMETHING but it's not clear exactly what that > something should be. Hopefully people that do such things will be > sufficiently technically sophisticated to be able to characterize their > problems based on the versions of any relevant FreeBSD packages. > > On the release of 11.1 there would be a complete new set of system > packages generated, and the upgrade process would install the new > versions of those packages all round, even if the content of an > individual package was identical to the one in 11.0. There's probably a > handy optimization where we compare the before and after checksums for > package files and don't overwrite on disk what is identical between > package versions, but do update all of the bookkeeping in the pkgdb. New numbering scheme is very hard problem... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Matthew Seaman wrote on 04/20/2016 12:43: On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. This will be a really nice feature which can save a lot of bandwidth and storage for backups after upgrade. (but I don't know how many files are usually unchanged between upgrades) Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. I really like FreeBSD, I am using it for more than 15 years on daily basis. FreeBSD had good and bad times (releases / changes) but one thing stays always the same - still bad communication about new features, work in progress etc. I think it is not too hard to publish papers about new base packages. Proposals, current state, ToDo to better inform users about upcoming changes. I think these informations already exist in some private form between developers. If these informations were more public I think there will be less annoyed posts in mailinglist and more constructive critics / ideas / patches. I did a guick search and found only one closely related page about packaged base: https://wiki.freebsd.org/FreeBSD-ng last edited 2014-03-11 Even this old page has "Known problems" mentioning the situation what we have now in this thread (fed-up people on both sides). So I think this was expected and people involved in this project could have do communication better. I had some concerns about it and some of them were explained and canceled after reading more than 100 posts in this thread. (some concerns remain). I believe if it was written in FreeBSD Wiki, there were not be so much dissapointed posts. I don't want to offend anybody on this list or FreeBSD team. I just think that things like this can and should be communicated better next time. Sysadmins and sysdevelopers have different point of view to a lot of things and it is better to talk about it before things are done and cannot be undone. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/20/16 10:48, Slawa Olhovchenkov wrote: > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. > > How do this with many packages? Hmmm Good point. At release time, a set of packages will be generated. These will all have the version number of the release eg. 11.0. That's simple and unambiguous. Subsequently adding patches will add a patch level to the version, so 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel will cause the output of uname(1) to show the new patch level, but updates to user land should be reflected in the output of freebsd-version(1). That's exactly the same as now, and assuming you, as an end user, install the default set of FreeBSD packages and apply all the patches as they come out, then there should be no problem. This implies that /every/ patchset will include an update to the package containing freebsd-version. What packaging base does do is allow you to be selective in the patches you apply. So, for instance if patch -p1 was not relevant to you, you might not install it. So you could end up with a system where you hadn't installed patches -p1 -- -p9 but you did install patch -p10. The freebsd-version(1) output would presumably show the system as 11.0-p10 -- but that's certainly not the same as a system with all of those patches -p1 to -p9 applied. Or you could just install the updated freebsd-version(1) package and have your system blatantly lie about its patching status. So, yes, this does change the meaning of the version number string. It's morally equivalent to tracking the releng/11.0 branch in SVN but compiling your system with various WITH_FOO or WITHOUT_BAR flags, and possible local modifications to the code base to back out certain commits. It's still 11.0-SOMETHING but it's not clear exactly what that something should be. Hopefully people that do such things will be sufficiently technically sophisticated to be able to characterize their problems based on the versions of any relevant FreeBSD packages. On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > IMO, the number of packages per-se is not a problem as long as you > can manage them without arcane commands, aliases, pipe - filters, > or scripts. (they all have their place, but less , the better) My > point is that I don't really want to keep on my head a Unix hacker > hat. I (and presumably many other humans ) like simple things,which > allow me to type a short command (preferably the whole system should > be simple enough to be explained in one-two pages in handbook) , > wait for completion, and get on with my life. Yes and no. While number of packages don't see outside internal -- this is irrelevant. After possibility of update individual package -- nuber of packages is impotant. Take fresh 11.0. Before 11.1 update only kernel. What you system have? 11.0? 11.1-RC3? How you name it? How identify it for take support on forum or mail list? How name system, updated all w/o compiler? or only some services? Currently we have simple naming: 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. This is shortly and clearly identify system to anyone. How do this with many packages? I am describe in -pkgbase expirence of updating system. How I am can naming this (my) system? Solaris don't ship new version often and don't have rollover updates. I think, first step may be split to only two package (kernel and world) and resolve many other issuses: distinc base packages from port packages, beadm compatibility, /etc and config updates (/etc/rc.d is not config but currently allowed to editing, this is distinct from plain ports configs) and others. After expirence with this next step will be more clear. > When I said people should pay more attention to Redmond and Cupertino, this > is what I meant. UIs are important. Easy service management, fault reporting > and so on should be automated. We shouldn't waste our time doing what the > computer should do in the first place. Most people want to get the job > done, so they can proceed with what is important for them. I am very sorry > if this is so offensive to some people that they feel attacked, but > unfortunately there aint much I can do to alleviate this. > > > > > 1) The number of packages that the base system has. > > 2) The user interface by which the packages are presented. > > > > I believe (and, please, correct me if I’m wrong), that all of the > > complaints in this thread have been about the UI, not about the underlying > > mechanism. That’s not to say that they’re unimportant (quite the reverse), > > but that they can be solved concurrently with the task of preparing the > > base system for distribution in packaged form. > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
IMO, the number of packages per-se is not a problem as long as you can manage them without arcane commands, aliases, pipe - filters, or scripts. (they all have their place, but less , the better) My point is that I don't really want to keep on my head a Unix hacker hat. I (and presumably many other humans ) like simple things,which allow me to type a short command (preferably the whole system should be simple enough to be explained in one-two pages in handbook) , wait for completion, and get on with my life. When I said people should pay more attention to Redmond and Cupertino, this is what I meant. UIs are important. Easy service management, fault reporting and so on should be automated. We shouldn't waste our time doing what the computer should do in the first place. Most people want to get the job done, so they can proceed with what is important for them. I am very sorry if this is so offensive to some people that they feel attacked, but unfortunately there aint much I can do to alleviate this. > > 1) The number of packages that the base system has. > 2) The user interface by which the packages are presented. > > I believe (and, please, correct me if I’m wrong), that all of the complaints > in this thread have been about the UI, not about the underlying mechanism. > That’s not to say that they’re unimportant (quite the reverse), but that they > can be solved concurrently with the task of preparing the base system for > distribution in packaged form. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20 Apr 2016, at 06:06, Julian Elischer wrote: > > my problem with 400 packages is that is is hard to decide what you are > actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? > you have no way to tell exactly what you have without comparing all the > packages to a known list. > uname doesn't mean much, nor does "__FreeBSD_version" if everything comes > with its own versions. I think that it’s very important, for the purpose of a constructive discussion, to separate the two concerns: 1) The number of packages that the base system has. 2) The user interface by which the packages are presented. I believe (and, please, correct me if I’m wrong), that all of the complaints in this thread have been about the UI, not about the underlying mechanism. That’s not to say that they’re unimportant (quite the reverse), but that they can be solved concurrently with the task of preparing the base system for distribution in packaged form. Having fine-grained packages makes a lot of things possible that are difficult otherwise, but we do need to fix the UI. > the 'leaf' concept in pkg helps with this a bit, but we've always considered > FreeBSD bas as a sort of monalithic entity that moves forward together. > > you are running 10.1p8 pr 10.2p1 that tells you all you need to know. > If you now need to take into account 400 different dimensions you have a much > harder way to describe what you have.. > > I mentioned this before but I think hte answer is to make a change on the > way that "meta packages" are displayed by default in pkg. Part of the problem is that we don’t actually have metapackages. A metapackage is a package that *contains* other packages. What we actually have is empty packages that *depend on* other packages. The package tool has no way of distinguishing a package that you install for the sole purpose of installing its dependencies from one that you install because you want it (though having no files inside it might serve as an heuristic that would work). > If I install the meta package, I really don't want to see all the sub > packages tat are unchanged unless I add '-v'. On the other hand if I upgrade > a sub package I want to see that in the context of the metapackage. Similarly > if I uninstall of the subpackages. Doing this properly also requires the notion of optional default and non-default subpackages. I should be prevented from uninstalling (at least, without a lot of -f) non-optional subpackages. For example, on a small system where I’m not using zfs, I might uninstall the libzfs subpackage from freebsd-libs, but if I try to uninstall the libc package then the system should shout at me. > > so something like this would remove most of my objections: > > # pkg info > = system packages > FreeBSD-networking-11.0.2_1FreeBSD networking subsystem and > commands > - ipfw-11.0.2-1 ipfw tools (uninstalled) > - fbsd-tcpdump-11.0.2-1 Built in tcpdump tools (uninstalled) > * openssl-11.0.2-2Openssl support (upgraded CVE-123456 > FreeBSD-base-base-11.0.2-1 The absolute minimum booting base > system > [...] > external packages == > apache22-2.2.31Version 2.2.x of Apache web server with > prefork MPM. > apr-1.5.2.1.5.4Apache Portability Library > autoconf-2.69 Automatically configure source code on many > Un*x platforms > autoconf-wrapper-20131203 Wrapper script for GNU autoconf > [...] > > > Maybe I uninstalled ipfw because I use pf and I install the ports tcpdump so > I can remove the built in one. > I have installed a new openssl due to a bugfix.. > > This gives me a real instant feel for what I'm running.. > if I add -v then I see all 400 packages, but I really don't want to see them > 99.99% of the time > > I believe the "leaf" method gives close to this but if we could get the above > I'd have absolutely no objections. Thank you for this suggestion. I think that this is the sort of UI that makes a lot of sense (though having subpackage support would also be useful for ports). It’s also the kind of thing that I think we could persuade the Foundation to fund if there is not enough volunteer time to implement it. David smime.p7s Description: S/MIME cryptographic signature
Re: [CFT] packaging the base system with pkg(8)
On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >> > >> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >> > packages?! WHY?! What are reasons and goals to split base in such >> > enormous number of packages? >> >> Just a guess, having done the same thing myself: it means that updates can >> be >> more targeted. >> > > This is exactly the reason, which has been answered numerous times. I don't know what the "ideal" number of packages is. 755 does seem large. However, I see it being like KSE. In hindsight KSE was overly complicated and M:N threading wasn't the way to go. However, Julian's work brought native threading to FreeBSD. Something it sorely needed. Similarly, the packaging of base FreeBSD is something that has been desperately needed for a long time but the work to get there was simply overwhelming. Initially there will very likely be painful problems, but I'm comfortable that all those involved will course correct and converge on something that most people will be content with. I'm sure there are those with well articulated criteria for a different decomposition of base, with specifics on how and why. Those select individuals can contribute meaningfully to this discussion. Everyone else should just applaud their hard work and get back to work. There are plenty of bugs that could have been fixed in the time it would have taken to digest this whole thread. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20/04/2016 06:12, Daniel Eischen wrote: > [And it really bothers me that FreeBSD 'pkg list' behaves > like 'pkg files' or similar should. It seems intuitive > that 'pkg list' should list the packages, not all the files > in all the packages.] 'pkg list' is one of the aliases defined in the default pkg.conf -- if you want to rename it to 'pkg files' that's trivially easy. If there's any sort of consensus that 'pkg files' would be preferable in general then I'm sure that the sample pkg.conf can be fixed in git. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On 20/04/2016 2:25 PM, Daniel Eischen wrote: On Wed, 20 Apr 2016, Allan Jude wrote: On 2016-04-20 01:12, Daniel Eischen wrote: For one of our Solaris 11 boxes, which also serves as a VNC thin client server and NFS server, we have: [sol11] $ pkg list | wc -l 968 That server includes the gnome desktop, firefox, thunderbird, perl, python, wireshark, CDR tools, etc. So arguably, it is comparable to my FreeBSD desktop at home with KDE, firefox, thunderbird, and similar tools. For that FreeBSD box, and just for ports packages (since I don't have base pkg'd): [freebsd11] $ pkg info | wc -l 865 [And it really bothers me that FreeBSD 'pkg list' behaves like 'pkg files' or similar should. It seems intuitive that 'pkg list' should list the packages, not all the files in all the packages.] If you add in 750+ FreeBSD base packages (1600+), that seems like a very large number of packages. And upgrading ports packages is not always painless. For the 865 FreeBSD packages I have installed, only 27 of them are explicit - the rest are dependencies. I do not look forward to updating my packages, even with poudriere. There is usually manual intervention required. So it is with this experience that I do sort of cringe at having 750+ FreeBSD base packages. I do like maintaining Solaris 11 boxes much better with their pkg management, much better than the old patchadm. does 'pkg prime-list' give you watch you are looking for? (pkgs you explicitly installed) pkg prime-list does show the explicitly installed packages, not sure how one would know to use 'prime-list' since it doesn't appear in any of the man pages (looking at FreeBSD 10-stable right now). And it doesn't show version information, nor other option arguments that I can tell. pkg help prime-list says it's just an alias for "query -e '%a = 0' '%n'". Seems like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer, though I'm not sure how to get all the columns to line up nicely. equally missing from help is 'pkg leaf' These show that information needed is available.. it just needs to be presented right. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 04:22:31AM +, Glen Barber wrote: > On Wed, Apr 20, 2016 at 07:15:22AM +0300, dan_partelly wrote: > > On Wed, 20 Apr 2016 04:07:11 +, Glen Barber wrote: > > > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: > > >> > > >> > > > >> > Sadly the tenor and tone of the discussion isn’t one where progress > > is > > >> > made. The tone has been a bit toxic and demanding, which grinds > > people > > >> into > > >> > dust, rather than motivating them to fix things. You might call it a > > >> > discussion, but it reads to me more as a bunch of angry villagers > > >> storming > > >> > the castle. No good can come from that. Tone down the outrage by a > > >> factor > > >> > of 100 and try to have the conversation again. > > >> > > > >> > > >> I'm frankly perplexed by this statement. Its seldom I perceived so much > > > > >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you > > >> want one to exist, one where you can isolate yourself from the > > >> indentured > > >> peasants and anything they say. Beyond your thick walls you'll be well > > >> served, > > >> every idea outside your wals will be toned down by a factor of 100 by > > the > > >> time > > >> it reaches the lord, becoming total agreement with anything the lord > > >> thinks. > > >> > > >> I cant believe I wrote this shit. But then again, I cant believe you > > just > > >> wrote > > >> what you did. > > >> > > > > > > And it's responses like this that are severely demotivating. > > > > Such statements, such answers. But Im done with this. It degenerates > > in emotional outbursts, much to the shame of all parts involved. > > > > You're absolutely right. > > I apologize for offending you and the countless hours spent on getting > this new model correct. > > What was I thinking? Glen, you do hard work and we much appreciated to you. But some don't have fluent english, for examle, I, and I can't create political sentense on english, restrict to pithy and informative sentense. Also, I am to long work with many comercial vendors and have some deformation, for example, when introductin new feature and don't provide direct promise of save old competition functionality -- in near, very near future this functionality will be removed. Please, do direct promise and describe you vision. We only see you commit and nothing more, this is too smal and we worry. Yes, now 11 is -current. But after mont -- this is STABLE and nothing to change w/o POLA violation! Price of flaw now very high (for project in first case). Yes, FreeBSD need new model for update and upgrade. But this tool implemented once have long impact and need have compatible more then base system. I am want cool FreeBSD and try to help this, by my expirens in system maintenance (not only FreeBSD). My expirense talk: change is very expensive. May be need do not put 11 to stable. Or may be schedule to some month. Or except this suvsystem from POLA. I am don't know. What you vision? What main distribution will be used in 11-RELEASE? What status will be have base packaging in 11? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, 20 Apr 2016, Allan Jude wrote: On 2016-04-20 01:12, Daniel Eischen wrote: For one of our Solaris 11 boxes, which also serves as a VNC thin client server and NFS server, we have: [sol11] $ pkg list | wc -l 968 That server includes the gnome desktop, firefox, thunderbird, perl, python, wireshark, CDR tools, etc. So arguably, it is comparable to my FreeBSD desktop at home with KDE, firefox, thunderbird, and similar tools. For that FreeBSD box, and just for ports packages (since I don't have base pkg'd): [freebsd11] $ pkg info | wc -l 865 [And it really bothers me that FreeBSD 'pkg list' behaves like 'pkg files' or similar should. It seems intuitive that 'pkg list' should list the packages, not all the files in all the packages.] If you add in 750+ FreeBSD base packages (1600+), that seems like a very large number of packages. And upgrading ports packages is not always painless. For the 865 FreeBSD packages I have installed, only 27 of them are explicit - the rest are dependencies. I do not look forward to updating my packages, even with poudriere. There is usually manual intervention required. So it is with this experience that I do sort of cringe at having 750+ FreeBSD base packages. I do like maintaining Solaris 11 boxes much better with their pkg management, much better than the old patchadm. does 'pkg prime-list' give you watch you are looking for? (pkgs you explicitly installed) pkg prime-list does show the explicitly installed packages, not sure how one would know to use 'prime-list' since it doesn't appear in any of the man pages (looking at FreeBSD 10-stable right now). And it doesn't show version information, nor other option arguments that I can tell. pkg help prime-list says it's just an alias for "query -e '%a = 0' '%n'". Seems like "query -e '%a = 0' '%n\t%v\t%o'" is a little nicer, though I'm not sure how to get all the columns to line up nicely. -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 2016-04-20 01:12, Daniel Eischen wrote: > On Tue, 19 Apr 2016, Russell L. Carter wrote: >> >> What is missing from this debate is some perspective from the POV of >> actually existing packaging systems. I've been maintaining >> debian-stable + debian-testing systems for over 15 years. The number >> of packaging glitches I've had I can count on one hand. (I've been >> running FreeBSD systems since the *very* beginning.) >> >> It is much easier to maintain my debian systems than my FreeBSD >> systems. Actually, pkg + poudriere is like a dream. Better than >> apt-get, actually. Except right now it doesn't maintain the base >> system. >> >> So, how many packages are actually installed on one of my debian >> boxes? >> >> debian-testing box with fvwm (ie no gnome/kde) userland: >> >> rcarter@aristotle> dpkg --list | wc --lines >> 1571 >> >> FreeBSD-10/stable with the same userland packaged from ports: >> >> rcarter@feyerabend> pkg info | wc -l >> 833 >> >> The debian system, for basically identical functionality, installs 738 >> more packages. Obviously the FreeBSD box has no packages for the base >> system, so that is probably a significant part of the difference in >> installed packages. And the debian box is dramatically easier to >> maintain. I typically will drag a debian box across several debian >> release cycles, i.e., 6+ years, w/o ever doing anything more >> complicated than doing apt-get update; apt-get dist-upgrade every week >> or so. > > For one of our Solaris 11 boxes, which also serves as a VNC > thin client server and NFS server, we have: > > [sol11] $ pkg list | wc -l > 968 > > That server includes the gnome desktop, firefox, thunderbird, > perl, python, wireshark, CDR tools, etc. So arguably, it is > comparable to my FreeBSD desktop at home with KDE, firefox, > thunderbird, and similar tools. For that FreeBSD box, and > just for ports packages (since I don't have base pkg'd): > > [freebsd11] $ pkg info | wc -l > 865 > > [And it really bothers me that FreeBSD 'pkg list' behaves > like 'pkg files' or similar should. It seems intuitive > that 'pkg list' should list the packages, not all the files > in all the packages.] > > If you add in 750+ FreeBSD base packages (1600+), that seems > like a very large number of packages. And upgrading ports > packages is not always painless. For the 865 FreeBSD packages > I have installed, only 27 of them are explicit - the rest are > dependencies. I do not look forward to updating my packages, > even with poudriere. There is usually manual intervention > required. So it is with this experience that I do sort of > cringe at having 750+ FreeBSD base packages. > > I do like maintaining Solaris 11 boxes much better with their > pkg management, much better than the old patchadm. > does 'pkg prime-list' give you watch you are looking for? (pkgs you explicitly installed) -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, 20 Apr 2016, Julian Elischer wrote: my problem with 400 packages is that is is hard to decide what you are actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? you have no way to tell exactly what you have without comparing all the packages to a known list. uname doesn't mean much, nor does "__FreeBSD_version" if everything comes with its own versions. And perhaps I missed it in the large number of missives on pkg'ing base, but we should be able to list just base packages or host port packages. I don't know if that is on or off the table. the 'leaf' concept in pkg helps with this a bit, but we've always considered FreeBSD bas as a sort of monalithic entity that moves forward together. you are running 10.1p8 pr 10.2p1 that tells you all you need to know. If you now need to take into account 400 different dimensions you have a much harder way to describe what you have.. Solaris base packages seem to use the OS version in their pkg version number, for instance: sol11 $ pkg list | grep 0.5.11 | grep system/library system/library 0.5.11-0.175.3.1.0.3.0 system/library/boot-management 0.5.11-0.175.3.0.0.30.0 system/library/c++-runtime 0.5.11-0.175.3.0.0.24.0 system/library/c++/sunpro0.5.11-0.168 system/library/iconv/unicode-core0.5.11-0.175.3.0.0.26.2 system/library/iconv/utf-8 0.5.11-0.175.3.0.0.26.2 system/library/install 0.5.11-0.175.3.0.0.30.0 system/library/install/libinstzones 0.5.11-0.175.3.0.0.30.0 system/library/liblayout 0.5.11-0.175.3.0.0.26.2 system/library/libv12n 0.5.11-0.175.3.0.0.30.0 system/library/math 0.5.11-0.175.3.0.0.19.0 system/library/mmheap0.5.11-0.175.3.0.0.7.0 system/library/openmp0.5.11-0.175.3.0.0.2.0 system/library/platform 0.5.11-0.175.3.0.0.30.0 system/library/policykit 0.5.11-0.175.3.0.0.30.0 system/library/processor 0.5.11-0.175.3.0.0.30.0 system/library/security/crypto 0.5.11-0.175.3.1.0.4.0 system/library/security/gss 0.5.11-0.175.3.0.0.30.0 system/library/security/gss/diffie-hellman 0.5.11-0.175.3.0.0.30.0 system/library/security/gss/spnego 0.5.11-0.175.3.0.0.30.0 system/library/security/libsasl 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_kernel0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_softtoken 0.5.11-0.175.3.0.0.30.0 system/library/security/pkcs11_tpm 0.5.11-0.175.3.0.0.30.0 system/library/security/rpcsec 0.5.11-0.175.3.0.0.30.0 system/library/storage/libdiskmgt0.5.11-0.175.3.0.0.30.0 system/library/storage/libfcoe 0.5.11-0.175.3.0.0.30.0 system/library/storage/scsi-plugins 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-hbaapi 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-ima 0.5.11-0.175.3.0.0.30.0 system/library/storage/snia-mpapi0.5.11-0.175.3.0.0.30.0 system/library/storage/suri 0.5.11-0.175.3.0.0.30.0 system/library/storage/t11-sm-hba0.5.11-0.175.3.0.0.30.0 system/library/usb/libusb0.5.11-0.175.3.0.0.30.0 system/library/usb/libusbugen0.5.11-0.175.3.0.0.30.0 That's Solaris 11.3. I'm assuming the 5.11 is Solaris 11 and the 175.3 is the .3 update. The remaining digits must be the package versions. -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016, Russell L. Carter wrote: What is missing from this debate is some perspective from the POV of actually existing packaging systems. I've been maintaining debian-stable + debian-testing systems for over 15 years. The number of packaging glitches I've had I can count on one hand. (I've been running FreeBSD systems since the *very* beginning.) It is much easier to maintain my debian systems than my FreeBSD systems. Actually, pkg + poudriere is like a dream. Better than apt-get, actually. Except right now it doesn't maintain the base system. So, how many packages are actually installed on one of my debian boxes? debian-testing box with fvwm (ie no gnome/kde) userland: rcarter@aristotle> dpkg --list | wc --lines 1571 FreeBSD-10/stable with the same userland packaged from ports: rcarter@feyerabend> pkg info | wc -l 833 The debian system, for basically identical functionality, installs 738 more packages. Obviously the FreeBSD box has no packages for the base system, so that is probably a significant part of the difference in installed packages. And the debian box is dramatically easier to maintain. I typically will drag a debian box across several debian release cycles, i.e., 6+ years, w/o ever doing anything more complicated than doing apt-get update; apt-get dist-upgrade every week or so. For one of our Solaris 11 boxes, which also serves as a VNC thin client server and NFS server, we have: [sol11] $ pkg list | wc -l 968 That server includes the gnome desktop, firefox, thunderbird, perl, python, wireshark, CDR tools, etc. So arguably, it is comparable to my FreeBSD desktop at home with KDE, firefox, thunderbird, and similar tools. For that FreeBSD box, and just for ports packages (since I don't have base pkg'd): [freebsd11] $ pkg info | wc -l 865 [And it really bothers me that FreeBSD 'pkg list' behaves like 'pkg files' or similar should. It seems intuitive that 'pkg list' should list the packages, not all the files in all the packages.] If you add in 750+ FreeBSD base packages (1600+), that seems like a very large number of packages. And upgrading ports packages is not always painless. For the 865 FreeBSD packages I have installed, only 27 of them are explicit - the rest are dependencies. I do not look forward to updating my packages, even with poudriere. There is usually manual intervention required. So it is with this experience that I do sort of cringe at having 750+ FreeBSD base packages. I do like maintaining Solaris 11 boxes much better with their pkg management, much better than the old patchadm. -- DE ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20/04/2016 11:41 AM, Nathan Whitehorn wrote: On 04/19/16 20:15, Warner Losh wrote: On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. Maybe I missed an email in this thread, but I don't recall anyone completely rejecting the idea of packaging the base system. What I see is a discussion related to doing it in the best way possible. Sadly the tenor and tone of the discussion isn’t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. Warner Yes, and that tone raises everyone's defensive hackles, which is never good. I'm going to make a patch for a reduced package count and hopefully we can restart this discussion then. It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. -Nathan my problem with 400 packages is that is is hard to decide what you are actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? you have no way to tell exactly what you have without comparing all the packages to a known list. uname doesn't mean much, nor does "__FreeBSD_version" if everything comes with its own versions. the 'leaf' concept in pkg helps with this a bit, but we've always considered FreeBSD bas as a sort of monalithic entity that moves forward together. you are running 10.1p8 pr 10.2p1 that tells you all you need to know. If you now need to take into account 400 different dimensions you have a much harder way to describe what you have.. I mentioned this before but I think hte answer is to make a change on the way that "meta packages" are displayed by default in pkg. If I install the meta package, I really don't want to see all the sub packages tat are unchanged unless I add '-v'. On the other hand if I upgrade a sub package I want to see that in the context of the metapackage. Similarly if I uninstall of the subpackages. so something like this would remove most of my objections: # pkg info = system packages FreeBSD-networking-11.0.2_1FreeBSD networking subsystem and commands - ipfw-11.0.2-1 ipfw tools (uninstalled) - fbsd-tcpdump-11.0.2-1 Built in tcpdump tools (uninstalled) * openssl-11.0.2-2Openssl support (upgraded CVE-123456 FreeBSD-base-base-11.0.2-1 The absolute minimum booting base system [...] external packages == apache22-2.2.31Version 2.2.x of Apache web server with prefork MPM. apr-1.5.2.1.5.4Apache Portability Library autoconf-2.69 Automatically configure source code on many Un*x platforms autoconf-wrapper-20131203 Wrapper script for GNU autoconf [...] Maybe I uninstalled ipfw because I use pf and I install the ports tcpdump so I can remove the built in one. I have installed a new openssl due to a bugfix.. This gives me a real instant feel for what I'm running.. if I add -v then I see all 400 packages, but I really don't want to see them 99.99% of the time I believe the "leaf" method gives close to this but if we could get the above I'd have absolutely no objections. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 05:37:00AM +0300, dan_partelly wrote: > Year after year you hear about new GsoC projects, then nothing. I find > it hard to believe that none of those actually produced any useful code. The goal of GSoC is to introduce new people to FreeBSD more than it is to produce committable code. It's designed as a learning experience. Sometimes, it has the pleasant property of producing code that can be committed without rework, but not that often. mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> > "I've given your response all the consideration that I think it's due. > Please have > a nice day." Thank you, Warner. Knowing you did, brings warm feelings in my hearth. Please have a nice day. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 07:15:22AM +0300, dan_partelly wrote: > On Wed, 20 Apr 2016 04:07:11 +, Glen Barber wrote: > > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: > >> > >> > > >> > Sadly the tenor and tone of the discussion isn’t one where progress > is > >> > made. The tone has been a bit toxic and demanding, which grinds > people > >> into > >> > dust, rather than motivating them to fix things. You might call it a > >> > discussion, but it reads to me more as a bunch of angry villagers > >> storming > >> > the castle. No good can come from that. Tone down the outrage by a > >> factor > >> > of 100 and try to have the conversation again. > >> > > >> > >> I'm frankly perplexed by this statement. Its seldom I perceived so much > > >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you > >> want one to exist, one where you can isolate yourself from the > >> indentured > >> peasants and anything they say. Beyond your thick walls you'll be well > >> served, > >> every idea outside your wals will be toned down by a factor of 100 by > the > >> time > >> it reaches the lord, becoming total agreement with anything the lord > >> thinks. > >> > >> I cant believe I wrote this shit. But then again, I cant believe you > just > >> wrote > >> what you did. > >> > > > > And it's responses like this that are severely demotivating. > > Such statements, such answers. But Im done with this. It degenerates > in emotional outbursts, much to the shame of all parts involved. > You're absolutely right. I apologize for offending you and the countless hours spent on getting this new model correct. What was I thinking? Glen signature.asc Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
On Tue, Apr 19, 2016 at 9:59 PM, dan_partelly wrote: > > > > > Sadly the tenor and tone of the discussion isn’t one where progress is > > made. The tone has been a bit toxic and demanding, which grinds people > into > > dust, rather than motivating them to fix things. You might call it a > > discussion, but it reads to me more as a bunch of angry villagers > storming > > the castle. No good can come from that. Tone down the outrage by a > factor > > of 100 and try to have the conversation again. > > > > I'm frankly perplexed by this statement. Its seldom I perceived so much > sorrow and bitterness in 6 lines. There is no castle Warner, unless you > want one to exist, one where you can isolate yourself from the indentured > peasants and anything they say. Beyond your thick walls you'll be well > served, > every idea outside your wals will be toned down by a factor of 100 by the > time > it reaches the lord, becoming total agreement with anything the lord > thinks. > > I cant believe I wrote this shit. But then again, I cant believe you just > wrote > what you did. > "I've given your response all the consideration that I think it's due. Please have a nice day." Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, 20 Apr 2016 04:07:11 +, Glen Barber wrote: > On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: >> >> > >> > Sadly the tenor and tone of the discussion isn’t one where progress is >> > made. The tone has been a bit toxic and demanding, which grinds people >> into >> > dust, rather than motivating them to fix things. You might call it a >> > discussion, but it reads to me more as a bunch of angry villagers >> storming >> > the castle. No good can come from that. Tone down the outrage by a >> factor >> > of 100 and try to have the conversation again. >> > >> >> I'm frankly perplexed by this statement. Its seldom I perceived so much >> sorrow and bitterness in 6 lines. There is no castle Warner, unless you >> want one to exist, one where you can isolate yourself from the >> indentured >> peasants and anything they say. Beyond your thick walls you'll be well >> served, >> every idea outside your wals will be toned down by a factor of 100 by the >> time >> it reaches the lord, becoming total agreement with anything the lord >> thinks. >> >> I cant believe I wrote this shit. But then again, I cant believe you just >> wrote >> what you did. >> > > And it's responses like this that are severely demotivating. Such statements, such answers. But Im done with this. It degenerates in emotional outbursts, much to the shame of all parts involved. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 21:07, Glen Barber wrote: On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: Sadly the tenor and tone of the discussion isn’t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. I'm frankly perplexed by this statement. Its seldom I perceived so much sorrow and bitterness in 6 lines. There is no castle Warner, unless you want one to exist, one where you can isolate yourself from the indentured peasants and anything they say. Beyond your thick walls you'll be well served, every idea outside your wals will be toned down by a factor of 100 by the time it reaches the lord, becoming total agreement with anything the lord thinks. I cant believe I wrote this shit. But then again, I cant believe you just wrote what you did. And it's responses like this that are severely demotivating. Glen Yes, this is not helpful. Talking about walls and lords and whatever can only make people angry (or demotivated) and is never persuasive. This is really great work; there is a discussion about some nits in how to distribute the results that corresponds to maybe 1% of the total patch. -Nathan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 06:59:38AM +0300, dan_partelly wrote: > > > > > Sadly the tenor and tone of the discussion isn’t one where progress is > > made. The tone has been a bit toxic and demanding, which grinds people > into > > dust, rather than motivating them to fix things. You might call it a > > discussion, but it reads to me more as a bunch of angry villagers > storming > > the castle. No good can come from that. Tone down the outrage by a > factor > > of 100 and try to have the conversation again. > > > > I'm frankly perplexed by this statement. Its seldom I perceived so much > sorrow and bitterness in 6 lines. There is no castle Warner, unless you > want one to exist, one where you can isolate yourself from the indentured > peasants and anything they say. Beyond your thick walls you'll be well > served, > every idea outside your wals will be toned down by a factor of 100 by the > time > it reaches the lord, becoming total agreement with anything the lord > thinks. > > I cant believe I wrote this shit. But then again, I cant believe you just > wrote > what you did. > And it's responses like this that are severely demotivating. Glen signature.asc Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
> > Sadly the tenor and tone of the discussion isn’t one where progress is > made. The tone has been a bit toxic and demanding, which grinds people into > dust, rather than motivating them to fix things. You might call it a > discussion, but it reads to me more as a bunch of angry villagers storming > the castle. No good can come from that. Tone down the outrage by a factor > of 100 and try to have the conversation again. > I'm frankly perplexed by this statement. Its seldom I perceived so much sorrow and bitterness in 6 lines. There is no castle Warner, unless you want one to exist, one where you can isolate yourself from the indentured peasants and anything they say. Beyond your thick walls you'll be well served, every idea outside your wals will be toned down by a factor of 100 by the time it reaches the lord, becoming total agreement with anything the lord thinks. I cant believe I wrote this shit. But then again, I cant believe you just wrote what you did. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, Apr 19, 2016 at 09:15:47PM -0600, Warner Losh wrote: > > > On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: > > > > On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: > >> As far as I know, nobody is taking the source code or the Makefiles > >> away, so if somebody doesn't like the system being distributed with > >> pkg, they can very well roll their own. > >> > >> It's nice to see the level of enthusiasm the FreeBSD project can > >> muster, I just wish it wasn't always enthusiasm for stopping progress. > >> > > > > Maybe I missed an email in this thread, but I don't recall > > anyone completely rejecting the idea of packaging the base system. > > What I see is a discussion related to doing it in the best way > > possible. > > Sadly the tenor and tone of the discussion isn’t one where progress > is made. The tone has been a bit toxic and demanding, which grinds > people into dust, rather than motivating them to fix things. You > might call it a discussion, but it reads to me more as a bunch of > angry villagers storming the castle. No good can come from that. > Tone down the outrage by a factor of 100 and try to have the > conversation again. > As probably the most demotivated person to read through this onslaught of nonsense, I cannot agree more. Glen signature.asc Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 20:15, Warner Losh wrote: On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. Maybe I missed an email in this thread, but I don't recall anyone completely rejecting the idea of packaging the base system. What I see is a discussion related to doing it in the best way possible. Sadly the tenor and tone of the discussion isn’t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. Warner Yes, and that tone raises everyone's defensive hackles, which is never good. I'm going to make a patch for a reduced package count and hopefully we can restart this discussion then. It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. -Nathan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> On Apr 19, 2016, at 4:12 PM, Matthew Grooms wrote: > > On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: >> As far as I know, nobody is taking the source code or the Makefiles >> away, so if somebody doesn't like the system being distributed with >> pkg, they can very well roll their own. >> >> It's nice to see the level of enthusiasm the FreeBSD project can >> muster, I just wish it wasn't always enthusiasm for stopping progress. >> > > Maybe I missed an email in this thread, but I don't recall anyone completely > rejecting the idea of packaging the base system. What I see is a discussion > related to doing it in the best way possible. Sadly the tenor and tone of the discussion isn’t one where progress is made. The tone has been a bit toxic and demanding, which grinds people into dust, rather than motivating them to fix things. You might call it a discussion, but it reads to me more as a bunch of angry villagers storming the castle. No good can come from that. Tone down the outrage by a factor of 100 and try to have the conversation again. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016 20:09:30 +, "Poul-Henning Kamp" wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. Your statement, at least as pertaining to this particular exchange, is unfair by any criteria. I dont think anybody in their right mind would oppose the base packaging project, all I seen where concerns regarding the pkg maturity, and how it handles the sheer number of resulting packages. which, if you think a bit, are legitimate concerns, whatever you agree with this stance or not. Yes, it is high time for progress. It is high time that FreeBSD foundation uses a more sizable chunk of the donations it receives to pay for projects bringing progress in FreeBSD.Maybe it is also high time that companies which make millions using BSD OSes (like Juniper) would give something substantial back. Speaking of progress, somebody should take a look at the autoexec.bat system called rc, and pay (foundation money) to have it rewritten in a modern form , which allows service sane service management and a modern fault reporting interface. Have the FreeBSD foundation pay to port those from Solaris. Also, while here, take a good look at the base system , and use same foundation money to ensure you expose in libraries all critical interfaces to the OS. Next, get a decent IPC system (there is already code there for this in the form of Mach ports in NextBSD. Yeah, FreeBSD needs a better way to do IPC that posix and plain unix domain sockets. Code is speaking lauder than words, so please, use the opportunity created by Hubbard and his NextBSD to get a much needed IPC system in FreeBSD. To be fair, it is needed for progress. Lastly, look in a more timely manner to the summer of code projects which might have produced some useful code. Year after year you hear about new GsoC projects, then nothing. I find it hard to bleive that none of those actually produced any useful code. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 4/19/16 1:09 PM, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. +1000 -Alfred ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 19 Apr 2016, at 19:42, Matthew Grooms wrote: I suspect that most of the negative reactions people are having is due to the line being blurred between the base system and everything else. Historically there has always been a clear distinction. By packaging base and throwing it in with everything else, you erase that distinction. I certainly agree that the distinction is changing, but I wouldn't say it's being erased. In fact, I'd argue that a packaged base system will clarify the conversation around the base/not-base dichotomy by forcing us to think about the underlying distinctions rather than of the delivery mechanism. For instance, I'd say that the biggest blurring between base and ports doesn't come from packages, it comes from vendor branches. If the base system is "an atomic, maintained-by-us snapshot of all the stuff you need to get a computer running and bootstrap your applications"... well, first, stop me here if I'm wrong! Assuming I'm not entirely wrong: we have lots of code in base that is "built by the FreeBSD project" and entirely maintained by "us". However, there is also a lot of code in base that comes from an upstream source and is primarily maintained by "them" (who may overlap with "us"), yet is essential to building or using the FreeBSD base system. This is a necessity of modern life (compilers are good), and yet I'm not entirely clear on the distinction between a lightly-patched compiler that lives in our source tree and a lightly-patched compiler that lives in the ports tree. So, now that the base compiler and a ports compiler will be installed using the same tools, it might be worth thinking about how they're really different (if at all). Not that there are any good answers... Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 4/19/2016 3:09 PM, Poul-Henning Kamp wrote: As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. Maybe I missed an email in this thread, but I don't recall anyone completely rejecting the idea of packaging the base system. What I see is a discussion related to doing it in the best way possible. I suspect that most of the negative reactions people are having is due to the line being blurred between the base system and everything else. Historically there has always been a clear distinction. By packaging base and throwing it in with everything else, you erase that distinction. I suspect that if the 'base is different' concept was preserved in a more fundamental way, there would be less resistance. After all, is there that much difference between trusting freebsd-update to patch X files vs trusting pkg to update X packaged files? What if there were two classes of packages, base and general? To interact with a base package set, perhaps an additional command line argument could be required. If you do a 'pkg info' after an install, an empty package set is shown. If you do a 'pkg info --base' ( or whatever ) instead, you see the base package set installed. If you need to get back to just the base system, you run 'pkg delete *' without the --base arg. In other words, base retains it's distinction and pkg pretty much works the same as it does now ( without the new argument ). -Matthew ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
I am sorry to maybe sound like an old grudge here, but can somebody take a sweep at the bug reports filled against ports-mgt/pkg in the last year or so? Packaging base system is surely challenging and exciting task, and great bikesheed topic too, but there are lot of critical bugs in the code that are pretty trivial and easy to fix. I owe at least one and it had no attention whatsoever for a month or so. Almost to the point where I would put my "no response from: maintainer" asbestos on and start checking in some random patches. Searching bigzilla shows that I might not be alone. ( -Max On Tue, Apr 19, 2016 at 2:17 PM, Wolfgang Zenker wrote: > * Adrian Chadd [160419 22:36]: > > It's cool. I have positive and negative reactions, and I'm totally > > happy to let people try it out at a larger scale and learn from > > mistakes. > > right, thats what we have CURRENT for. Instead of discussing all > the things that could theoretically go wrong or make our live > easier/more difficult/whatever, let's just try it out and get > a feeling for it. > > Wolfgang > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
* Adrian Chadd [160419 22:36]: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. right, thats what we have CURRENT for. Instead of discussing all the things that could theoretically go wrong or make our live easier/more difficult/whatever, let's just try it out and get a feeling for it. Wolfgang ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, Apr 19, 2016 at 3:36 PM, Nathan Whitehorn wrote: > > > On 04/19/16 13:26, Poul-Henning Kamp wrote: >> >> >> In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes: >> >>> Oh yeah, now I remember: Because in freebsd, design is decided by a >>> race to commit rather than by discussion. >> >> No, that's not it. >> >> It is because code talks much louder than words. > If it would help, I am happy to generate a patch to make the discussion > concrete. > -Nathan Please do. Practical is always better than theory, in practice. It's easier to debate on practical grounds. - Justin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 at 01:36P, Nathan Whitehorn wrote: > > > On 04/19/16 13:26, Poul-Henning Kamp wrote: > > > > In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes: > > > >> Oh yeah, now I remember: Because in freebsd, design is decided by a > >> race to commit rather than by discussion. > > No, that's not it. > > > > It is because code talks much louder than words. > > > This is kind of a silly argument here since the code change is trivial. > There is a potentially large impact on the system that merits > discussion. Moreover, there is a whole bunch of other code still needs > to be written to make this workable in production that depends to some > degree on what choices are made here: what does pkg show for these? How > do upgrades work? The installer needs modifications to use pkg instead > of tar. It's not clear what the migration path to/from a packaged system > is, since the packaging is apparently optional. > > If it would help, I am happy to generate a patch to make the discussion > concrete. Thank you, Nathan. "code wins" is not the correct argument in this discussion, imo. Fwiw, I feel this is one of the sensible threads where things are being discussed without shouting/yelling/shaming. But thats my opinion. Cheers, Hiren pgpisYNukTf2G.pgp Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 13:26, Poul-Henning Kamp wrote: In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes: Oh yeah, now I remember: Because in freebsd, design is decided by a race to commit rather than by discussion. No, that's not it. It is because code talks much louder than words. This is kind of a silly argument here since the code change is trivial. There is a potentially large impact on the system that merits discussion. Moreover, there is a whole bunch of other code still needs to be written to make this workable in production that depends to some degree on what choices are made here: what does pkg show for these? How do upgrades work? The installer needs modifications to use pkg instead of tar. It's not clear what the migration path to/from a packaged system is, since the packaging is apparently optional. If it would help, I am happy to generate a patch to make the discussion concrete. -Nathan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Nathan Whitehorn wrote: Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is really met by having 800 packages, though, or at least I see no particular gain relative to a handful (where things like OpenSSL or sendmail would be discrete things). (Almost) every single individual library in the base system is right now its own single-file package, which is what I am objecting to. Hey Nathan. I admit to not having looked at it with the goal of consolidation. Presumably there will be libs that can be grouped but we should look at each consolidation's pros and cons. Baptiste's rational is the policy we have and, IMO, refinement should start at that (policy) level. The process has no doubt accelerated thanks this thread but aside from debug, profile and a few others it's not clear if there are grouping policies that would significantly bridge the gap between our respective goals. It's critical that we look at other distribution's package systems. My count packages on Linux and monolithinc-base FreeBSD desktops is about 2,500 and 700 respectively. Adding 383 base packages (assuming no debug or profile) would push this 28% ratio to 43% of Linux' package count. Of course servers will be different and our FreeBSD package counts would rise from the low to mid 100s to over 600 which is still only 60-70% of the packages on Linux servers I have access to. Having managed Linux systems with 1000 to 3000 packages I can't say that I have real concerns for pkgng in this regard. The package management tools have to scale of course but on a KIS scale more packages = less time spent for a given level of functionality and security (in my experience). I hope we can look forward to some top-level policy suggestions to further refine the base package schema. Roger ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tuesday, April 19, 2016, Adrian Chadd wrote: > It's cool. I have positive and negative reactions, and I'm totally > happy to let people try it out at a larger scale and learn from > mistakes. > > Because, honestly - fuck it, we've been behind for too long. We need > more mature tools and knowledge with this. > > The irony of course is the people rolling out docker are doing it > after finding that OS packages aren't the best granularity, but > "whatever the package systems in the software stack we're using, and > then tar the whole mess up and distribute it" method. Kinda like > FreeBSD > > > Those are different, semi-orthogonal problems. Please restate your last paragraph. I can't interpret your intent. -M > > -adrian > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
It's cool. I have positive and negative reactions, and I'm totally happy to let people try it out at a larger scale and learn from mistakes. Because, honestly - fuck it, we've been behind for too long. We need more mature tools and knowledge with this. The irony of course is the people rolling out docker are doing it after finding that OS packages aren't the best granularity, but "whatever the package systems in the software stack we're using, and then tar the whole mess up and distribute it" method. Kinda like FreeBSD -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes: >Oh yeah, now I remember: Because in freebsd, design is decided by a >race to commit rather than by discussion. No, that's not it. It is because code talks much louder than words. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Hi! > I don't see anybody, who say "remove this packaging code, it is all > completely wrong, BS, whatever". All objections are against mechanical > splitting base to 700+ packages, not against packaged base per se. I also run a bunch of boxes, and I do not have a problem with 700+ base packages on top of the other ones I use. But: I have not tested pkg base yet. I'm just a happy pkg user 8-} -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 19.04.2016 23:10, K. Macy wrote: I don't like to see, as some participants of this thread write their messages as if somebody in this thread are against packaging base with pkg. I don't see anybody, who say "remove this packaging code, it is all completely wrong, BS, whatever". All objections are against mechanical splitting base to 700+ packages, not against packaged base per se. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On Tue, 2016-04-19 at 20:09 +, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping > progress. > Why is it that anyone who tries to inject some aspect of concensus design into something is automatically labeled anti-progess? Oh yeah, now I remember: Because in freebsd, design is decided by a race to commit rather than by discussion. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tuesday, April 19, 2016, Poul-Henning Kamp wrote: > As far as I know, nobody is taking the source code or the Makefiles > away, so if somebody doesn't like the system being distributed with > pkg, they can very well roll their own. > > It's nice to see the level of enthusiasm the FreeBSD project can > muster, I just wish it wasn't always enthusiasm for stopping progress. +1 > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
As far as I know, nobody is taking the source code or the Makefiles away, so if somebody doesn't like the system being distributed with pkg, they can very well roll their own. It's nice to see the level of enthusiasm the FreeBSD project can muster, I just wish it wasn't always enthusiasm for stopping progress. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Tue, 19 Apr 2016 20:18:40 +0300, Lev Serebryakov wrote: > On 19.04.2016 19:28, Nathan Whitehorn wrote: > > > 3. Have ~10 meta packages that just depend on sets of the 755 packages > > and hide the internal details. This gives the user experience of (1) > > with the implementation of (2), and is marginally more complex than either. > How does it help Slawa with his broken system when "pkg upgrade" > replace only half of "base" packages? > > Meta-packages as they are now: "no files, only dependencies" doesn't > help here at all. > > Really, if I want "base but no sendmail" I want easy way to see it > after 5 years after installation, and 755 packages, covered or not by > meta-packages, will need me to read all list of 754 packages to see, > that there is no sendmail, for example. It is trivial example, but it is > completely valid. And there are many other such corner cases, which is > common for administrators and ops, but not for developers. > > Please, consider ops and admins, who must support old installations, > often made by other, not-reachable, people, and stuff like this, > > -- > // Lev Serebryakov Thoughts PRO pkg base from here: it can fix a broken installworld that breaks midway rendering the system no able to login, not able to compile or install futher, or some other event... Can those failures be crafted purposely to show how the could be readily per procedure if a usual installworld fails? Thoughts ANTI pkg base from here: Several, but I have thought of more work required for developers who have custom kernels and a large amount of code that is BETA and not READY yet and are slowed down by conforming to additional pkg-base requirements.. hindering creativity ... Sparse initial documentation or at some time not upto par ... *FLOWCHART" demonstrating precisely the relationship between a pure-pkg-base and pure-svn-base system, a mixture of the two, how to migrate parts/all of one to the other, one edge a desired install or several types of same, the other (two) edges where one starts out from... that could be updated over the years for a comprehensive overview. [ AS AN ASIDE, ] I always tend to think that as missing already in pkg, svn, synth, poudriere, jails, chroot, wpa_supplicant, ndisalator, linux-c6, binutils >> << gcc , zfs, ssh_config, ipfw, pf, geli, gpart, UEFI, xorg.conf, some individual ports, [ I should stop typing here, because even as I type more things come to mind... problem with a port ? pr OR maintainer OR documentation OR... flowchart... etc ] stuff-to-leave-out-or-include-in-a-kernel, buildworld/installworld, ppp.conf, NOT AS CRITICISM but as "Why is it not at least as good for newbies to each concept or better than a WIKI !!! as not only the simplified explanation sometimes can be made more apparent of which cli to issue next, but time spent reading stuff NOT specific to the task at hand is saved. Adequate testing? some breakage bound to happen... fixing such breakage procedures in place? A UPDATING for pkg-base specifically? Again, not wishing to waste one's time, just writing down what I've thought of so far, freely simply file it away rather than reply online... my answers to any reply could simply re-iterate the background to the above (I am NOT well versed in many topics of FreeBSD, just in the more useful ones at the installs that I use daily... ). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 11:22, Nathan Whitehorn wrote: On 04/19/16 10:55, Roger Marquis wrote: Please, consider ops and admins, who must support old installations, often made by other, not-reachable, people, and stuff like this, Ops and admins such as myself are exactly the ones who will benefit most from base packages. Being able run to: 1) 'pkg audit' and see that base ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those specific parts of base that need to be updated is far simpler (KIS) and faster than what we go through now. More than a few formerly bsd shops have migrated to linux simply to avoid regular iterations of cd /usr/src; svn up; make cleanworld; make buildworld installworld ... The use cases for granular base packages are more numerous than even these obvious ones. The downside OTOH, seems to consist of not much more than the size of the package list. If I missed other issues please do clarify. Will base packages be improved, sure, but they're already more useful and bugfree than pkgng when it was mandated. In any case, if I'm not mistaken base packages are entirely optional. Roger Marquis Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is really met by having 800 packages, though, or at least I see no particular gain relative to a handful (where things like OpenSSL or sendmail would be discrete things). (Almost) every single individual library in the base system is right now its own single-file package, which is what I am objecting to. The upside of that seems pretty dubious and the downside is that it is much easier to accidentally put the system into an inconsistent state. Is there a reason you want to have such very fine discretization? -Nathan What is missing from this debate is some perspective from the POV of actually existing packaging systems. I've been maintaining debian-stable + debian-testing systems for over 15 years. The number of packaging glitches I've had I can count on one hand. (I've been running FreeBSD systems since the *very* beginning.) It is much easier to maintain my debian systems than my FreeBSD systems. Actually, pkg + poudriere is like a dream. Better than apt-get, actually. Except right now it doesn't maintain the base system. So, how many packages are actually installed on one of my debian boxes? debian-testing box with fvwm (ie no gnome/kde) userland: rcarter@aristotle> dpkg --list | wc --lines 1571 FreeBSD-10/stable with the same userland packaged from ports: rcarter@feyerabend> pkg info | wc -l 833 The debian system, for basically identical functionality, installs 738 more packages. Obviously the FreeBSD box has no packages for the base system, so that is probably a significant part of the difference in installed packages. And the debian box is dramatically easier to maintain. I typically will drag a debian box across several debian release cycles, i.e., 6+ years, w/o ever doing anything more complicated than doing apt-get update; apt-get dist-upgrade every week or so. Now I much prefer poudriere + pkg over apt-get, because I can tune my package dependencies. What I do is make the implicit meta-packages effectively even more fine grained, by excluding stuff I don't need. My conclusion is that it's not obvious that a large number of packages makes a system harder to maintain. It seems to me, the opposite. Now I watch a few debian lists so I know glitches happen, but not to me very often. I don't have much experience locking down a system to just major releases with only security updates, but I don't think debian-stable has very many issues doing exactly that. In my opinion, what the package team is doing is extremely cool, technically. I run poudriere builds every night, keeping up to date with ports-svn. It's just so much better than debian's kitchen sink one-size-fits-all approach to package dependencies. In a container world, it seems to me this is basically a killer app. Best to all, Russell ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/19/16 10:55, Roger Marquis wrote: Please, consider ops and admins, who must support old installations, often made by other, not-reachable, people, and stuff like this, Ops and admins such as myself are exactly the ones who will benefit most from base packages. Being able run to: 1) 'pkg audit' and see that base ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those specific parts of base that need to be updated is far simpler (KIS) and faster than what we go through now. More than a few formerly bsd shops have migrated to linux simply to avoid regular iterations of cd /usr/src; svn up; make cleanworld; make buildworld installworld ... The use cases for granular base packages are more numerous than even these obvious ones. The downside OTOH, seems to consist of not much more than the size of the package list. If I missed other issues please do clarify. Will base packages be improved, sure, but they're already more useful and bugfree than pkgng when it was mandated. In any case, if I'm not mistaken base packages are entirely optional. Roger Marquis Thanks, Roger. That seems perfectly reasonable. I'm not sure that goal is really met by having 800 packages, though, or at least I see no particular gain relative to a handful (where things like OpenSSL or sendmail would be discrete things). (Almost) every single individual library in the base system is right now its own single-file package, which is what I am objecting to. The upside of that seems pretty dubious and the downside is that it is much easier to accidentally put the system into an inconsistent state. Is there a reason you want to have such very fine discretization? -Nathan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Please, consider ops and admins, who must support old installations, often made by other, not-reachable, people, and stuff like this, Ops and admins such as myself are exactly the ones who will benefit most from base packages. Being able run to: 1) 'pkg audit' and see that base ssl has a vulnerability, 2) 'pkg install -f' to update 3) only those specific parts of base that need to be updated is far simpler (KIS) and faster than what we go through now. More than a few formerly bsd shops have migrated to linux simply to avoid regular iterations of cd /usr/src; svn up; make cleanworld; make buildworld installworld ... The use cases for granular base packages are more numerous than even these obvious ones. The downside OTOH, seems to consist of not much more than the size of the package list. If I missed other issues please do clarify. Will base packages be improved, sure, but they're already more useful and bugfree than pkgng when it was mandated. In any case, if I'm not mistaken base packages are entirely optional. Roger Marquis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 19.04.2016 19:36, Alfred Perlstein wrote: > Why is this even happening in email? If folks want "the right solution" > then why aren't they submitting patches or pull requests to the pkg repo > (or where ever this is stored?). This seems counter-intuitive, but > really actually should be how it works. Ops should send patches with non-trivial code? Please, keep it in mind: here are thousands of SYSTEM ADMINISTRATORS / OPS (not fancy and trendy DevOps), who will use (and praise or suffer) new packaged system. Many of them understand, what is good and what is bad for them, but they CAN NOT and SHOULD NOT code in C and "submit patches". Now your, effectively, say "we are interested only in opinions of developers, not end-users". It is wtong-wrong-wrong. It is what Slawa try to tell: not developers will support thousands of servers which will have 755 packages only for base system, but admins and ops, and they have OTHER priorities over developers. And, of course, most of them could not send high-quality patches to such complex pieces of software as pkg or FreeBSD build system. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On 19.04.2016 19:28, Nathan Whitehorn wrote: > 3. Have ~10 meta packages that just depend on sets of the 755 packages > and hide the internal details. This gives the user experience of (1) > with the implementation of (2), and is marginally more complex than either. How does it help Slawa with his broken system when "pkg upgrade" replace only half of "base" packages? Meta-packages as they are now: "no files, only dependencies" doesn't help here at all. Really, if I want "base but no sendmail" I want easy way to see it after 5 years after installation, and 755 packages, covered or not by meta-packages, will need me to read all list of 754 packages to see, that there is no sendmail, for example. It is trivial example, but it is completely valid. And there are many other such corner cases, which is common for administrators and ops, but not for developers. Please, consider ops and admins, who must support old installations, often made by other, not-reachable, people, and stuff like this, -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
I don't think we need 100% consensus to proceed on anything and if I've learned anything from 20 years in this community is that forcing that issue does the community a huge disservice as well as turn off the code submitters. See my thread on the missed opportunities in threads, or if you want I can paint the picture of what caused SMP to lag half a decade behind Linux as well. I would say that if someone submitted a patch for /dev/givemeroot, sure that would be righteously shot down but to force the whole, entire, "right" solution the first time around is remarkably blocking and unfair to the community and submitters as well. Why is this even happening in email? If folks want "the right solution" then why aren't they submitting patches or pull requests to the pkg repo (or where ever this is stored?). This seems counter-intuitive, but really actually should be how it works. Specifically: if you like where an idea is going, then don't block the code, submit improvements on top of it. Stone soup it if you will. -Alfred On 4/19/16 9:28 AM, Nathan Whitehorn wrote: Well, this discussion has gone pretty far off of the rails. I am of course happy to make a patch that cuts this down to 10 packages, but that's not something that should be committed without agreement -- which we obviously don't have. It would have been good to have had meaningful discussion of this before. There are basically three workable options: 1. Have fewer packages. This is easy to implement and preserves the integrity of the base system (as well as unified versioning so that a system at some particular patch level will have the same global state). I have not seen any meaningful downside suggested to this so far except for marginally higher load on update servers. 2. Have 755 packages. This makes it harder to version the system and makes the user interface significantly worse (my opinion, but shared by others). This is the easiest to implement since it is already implemented. 3. Have ~10 meta packages that just depend on sets of the 755 packages and hide the internal details. This gives the user experience of (1) with the implementation of (2), and is marginally more complex than either. Other things (the overlapping packages idea, for instance) are way too complex and will just lead to breakage. Can anyone provide an argument against (1) or, alternatively, for (2)? (2) seems to add a lot of complexity for no clear gain and I remain pretty confused about why it was chosen. -Nathan On 04/18/16 20:17, Alfred Perlstein wrote: Maybe what the "too many packages" folks need to do is write some code to hide that it's so many packages. :) I think the rule of two feet should be applied here. What we have is people that have worked quite hard to bring us something that we can easily work with, and on the other hand some folks that want something they consider even better. Personally I can't see how having the system less granular is better, since having it MORE granular is actually harder work. Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted to make it less granular all they would have to do is make some meta-packages. -Alfred On 4/18/16 7:23 PM, Lyndon Nerenberg wrote: On 2016-04-18 7:01 PM, Roger Marquis wrote: Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports. The ports tree isn't a mandatory part of the system. And by definition it could not be tested that way, since it offers so many alternative implementations of specific functionality. Other operating systems don't do that for their base packages. I'm pretty sure Solaris had some fairly hard-core regression tests to ensure basic system functionality wouldn't be compromised by 'oddball' selections of packages offered up at install time. > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. The concern is from all of us UNIX dinosaurs who predate the fine-grained packaging environment, which just worked, and who now rip our (little remaining) hair out due to unsolvable package dependency loops in the Linux machines we are forced to administer in order to pay rent. For me, as a sysadmin, I derive a negative benefit from this optimization. I guess what I'm really asking is: where is the peer reviewed research that shows this actually improves things for the not-1% of FreeBSD users? --lyndon P.S. Don't turn this into a pissing match. I really want to know how this is of net benefit to everyone. But I don't want hyperbole. I have looked at a lot of, e.g., USENIX and ACM, bibliographies and papers for justification for this, and I can'
Re: [CFT] packaging the base system with pkg(8)
Well, this discussion has gone pretty far off of the rails. I am of course happy to make a patch that cuts this down to 10 packages, but that's not something that should be committed without agreement -- which we obviously don't have. It would have been good to have had meaningful discussion of this before. There are basically three workable options: 1. Have fewer packages. This is easy to implement and preserves the integrity of the base system (as well as unified versioning so that a system at some particular patch level will have the same global state). I have not seen any meaningful downside suggested to this so far except for marginally higher load on update servers. 2. Have 755 packages. This makes it harder to version the system and makes the user interface significantly worse (my opinion, but shared by others). This is the easiest to implement since it is already implemented. 3. Have ~10 meta packages that just depend on sets of the 755 packages and hide the internal details. This gives the user experience of (1) with the implementation of (2), and is marginally more complex than either. Other things (the overlapping packages idea, for instance) are way too complex and will just lead to breakage. Can anyone provide an argument against (1) or, alternatively, for (2)? (2) seems to add a lot of complexity for no clear gain and I remain pretty confused about why it was chosen. -Nathan On 04/18/16 20:17, Alfred Perlstein wrote: Maybe what the "too many packages" folks need to do is write some code to hide that it's so many packages. :) I think the rule of two feet should be applied here. What we have is people that have worked quite hard to bring us something that we can easily work with, and on the other hand some folks that want something they consider even better. Personally I can't see how having the system less granular is better, since having it MORE granular is actually harder work. Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted to make it less granular all they would have to do is make some meta-packages. -Alfred On 4/18/16 7:23 PM, Lyndon Nerenberg wrote: On 2016-04-18 7:01 PM, Roger Marquis wrote: Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports. The ports tree isn't a mandatory part of the system. And by definition it could not be tested that way, since it offers so many alternative implementations of specific functionality. Other operating systems don't do that for their base packages. I'm pretty sure Solaris had some fairly hard-core regression tests to ensure basic system functionality wouldn't be compromised by 'oddball' selections of packages offered up at install time. > Honestly, some of us are wondering what exactly is > behind some of these concerns regarding base packages. The concern is from all of us UNIX dinosaurs who predate the fine-grained packaging environment, which just worked, and who now rip our (little remaining) hair out due to unsolvable package dependency loops in the Linux machines we are forced to administer in order to pay rent. For me, as a sysadmin, I derive a negative benefit from this optimization. I guess what I'm really asking is: where is the peer reviewed research that shows this actually improves things for the not-1% of FreeBSD users? --lyndon P.S. Don't turn this into a pissing match. I really want to know how this is of net benefit to everyone. But I don't want hyperbole. I have looked at a lot of, e.g., USENIX and ACM, bibliographies and papers for justification for this, and I can't find it. It would really help (me, at least) if someone could take a moment to point me at demonstrable evidence of the benefits of this model. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 19.04.2016 17:33, Alfred Perlstein wrote: > I am also confident that we will very easily sort out how to make > "micropackages" or some such mechanism within at most 3 months after the > code lands. The reason why is because I already see some excellent > proposals for such mechanisms in this thread. I could see only two proposals: meta-packages (which is not a solution, but kludge, IMHO) from numerous people and proposal from Slawa about "overlapped" and "file-removal" packages, which is not discussed at all (https://lists.freebsd.org/pipermail/freebsd-current/2016-April/060688.html). I really like Slawa approach, but it requires much more sophisticated pkg, including additional metadata, etc. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On Tue, Apr 19, 2016 at 08:18:48AM -0700, Alfred Perlstein wrote: > 1) Graciously and rapidly accept steps forward and then contribute to > them. Anything else leaves you stagnant and worse for wear. > 2) Simple over complex. > 3) If something someone else did is working for someone, then copy it > and move on, don't waste a huge amount of your customer's time trying to > make something better until you are sure that just copying it will not > suffice. What is simple -- split base to 10 packages or split base to 800 packages? I think first. What need for succesufult moved forward after this? I think ability of spliting and mergering packages at upgrade. (clang-base => clang-base-c + clang-base-c++, for example. or clang-base-c + clang-base-c++ => clang-base). What need for security updates? I think ability to have file with common name and different content with multiple installed packages: base-11.0 contains /usr/sbin/ntpd base-11.0-CVE-1234 direct depends to base-11.0 and contains overlaped /usr/sbin/ntpd As result: few packages, compact security updates, ability to repackage base. Optionaly, ability to have packages with "dummy" content, for example no-base-ntp-11.0 have record (w/o actual content) about /usr/sbin/ntpd with size -791552 (negative size) and checksum of actual file, for removing some components. For this feature give ability to have "skins" packages, installed over main package. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"