| zcot | Hi all, I was hoping I could get a review of this packaging attempt. The goal is to put it up as a ppa and get some feedback and work from there: https://code.launchpad.net/~zcotcaudle/+junk/list-apt-installs | 01:05 |
|---|---|---|
| zcot | I do wonder, in many packages I see where source and package names are named for example "name" and "name-dev"(in debian/control file). Is this a necessity, should I be concerned about that? | 01:08 |
| zcot | also, can someone point to some cycle info or something about the general development path using a project with packaging. I see so many projects on github with a /debian packaging tree within the source but I was under the impression it is better to keep source and packaging separated. I feel like as long as it's under bazaar control the source will always retain each packaging increment, so that should be good there. What's the idea with this? | 01:14 |
| rbasak | zcot: packaging-wise it looks fine. I would probably add a Depends on apt without apt the program cannot work at all. | 10:34 |
| rbasak | zcot: a -dev package isn't necessary as you aren't shipping a C library. | 10:34 |
| rbasak | zcot: I'm not sure whether a new source in the Ubuntu archive is appropriate for this though. | 10:34 |
| rbasak | zcot: or that a C program is particularly maintainable to solve this problem | 10:35 |
| rbasak | zcot: it'd increase the proliferation of uncoordinated apt-related tools in the archive. Better to work with apt upstream or similar and get the same functionality shipped inside there or a related existing package (like the same place add-apt-repository is shipped). | 10:36 |
| rbasak | zcot: also there's no manpage or other on-system usage documentation that I can see. | 10:36 |
| rbasak | zcot: I suggest talking to apt maintainers in the first instance, or failing that consider adding this functionality to software-properties-common (to join add-apt-repository) or perhaps something in relation to an apport hook. | 10:37 |
| rbasak | zcot: it generally works better to keep a separate packaging branch that adds the debian/ directory. Otherwise tweaks to the debian directory have to land in master, which bumps it, which means that you have to bump the upstream version number in packaging and end up in a loop. | 10:38 |
| zcot | rbasak: Thank you. That all seems like good and useful info. upstream seems good, I was too far downstream using a backup scheme tool to see it. | 15:22 |
| zcot | the -dev name thing. well in this case i was thinking -source (or whatever), but just for the idea that the source package is different, but I guess they are distributed based on the user choice so in the end it doesn't matter.. either a user can get the source or the binary. | 15:23 |
| rbasak | zcot: source package names exist in a separate namespace from binary package names. In the typical case for a simple package, the source package name is identical to the binary package name. | 15:25 |
| zcot | rbasak: I appreciate the feedback. I'll keep working on this thing. (well even there is no "system usage" to be documented other than invocation. lol) | 15:26 |
| rbasak | zcot: thanks. This sort of thing might be quite useful in an apport hook too. Ubuntu bug triagers will thank you for it. | 15:27 |
| zcot | rbasak: ok. great. that's what I was thinking, but wasn't sure about the naming. but they are really different so the name isn't a clash. | 15:28 |
| zcot | rbasak: yea, I'll have to dig further on that one. ;) -no just winging a few lines together and call it done. lol | 15:29 |
| zcot | rbasak: as for "Depends" I was thinking that was strictly in line with building and running, which apt is not required. so is this a case for checking into Recommends and Suggested related section? or it truly should Depend on apt and/or apt-get (it honestly would be useless without them). | 15:37 |
| zcot | that's deeper into good package management I guess, of which I have only scarcely touched the basics of at this point. | 15:39 |
| rbasak | That's a good reason to make it Recommends I suppose. | 15:40 |
| rbasak | Especially if the program is capable of examining apt logs from other systems (eg. with a path override on where it looks). | 15:40 |
| zcot | ah! ok, excellent. :) Thank you again rbasak. | 15:42 |
| === Elimin8r is now known as Elimin8er | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!