[Aptitude-devel] Bug#964916: Option to allow packages from backports but without forcing it

Pirate Praveen praveen at onenetbeyond.org
Sun Jul 12 20:38:16 BST 2020



On Sun, Jul 12, 2020 at 19:16, Jessica Clarke <jrtc27 at debian.org> wrote:
> On 12 Jul 2020, at 18:39, Pirate Praveen <praveen at onenetbeyond.org> 
> wrote:
>>  On Sun, Jul 12, 2020 at 21:50, Pirate Praveen 
>> <praveen at onenetbeyond.org> wrote:
>>>>  Erm… I did add buster-backports, the official one.
>>>>  You absolutely cannot have a thing called buster-backports on the
>>>>  fasttrack server because that’s too easily confused with the
>>>>  official one.
>>>  Let me think about it.
>> 
>>  Usually with the same suite name, I just have to upload the same 
>> .changes file when the package enters testing. So changing the name 
>> just adds extra busy work (multiple changelog entries and rebuilds) 
>> without any real benefit. Like in the case of ruby-faraday, I just 
>> had to dput the .changes file I already created for 
>> fasttrack/buster-backports to official buster-backports. So I will 
>> stick with it unless someone can show me some real advantage.
> 
> This response is, quite frankly, extremely rude and disrespectful 
> towards
> Thorsten. Your "without any real benefit" completely disregards the 
> original
> reason given which, as you can see above is "because that’s too 
> easily confused
> with the official one.". As for the approach, do not do this. 
> Seriously.
> Whatever your motivation. If seasoned DDs are being confused by you 
> creating
> your own thing with an identical name to a core part of Debian, how 
> on earth do
> you expect users to not be confused out of their minds? Not to 
> mention it's
> going to seriously aggravate those who manage the real backports 
> suites and
> those who follow these lists, as there will no doubt be users coming 
> along
> complaining about things that apply to your name-hijacked version and 
> not the
> actual backports suites. So call it something else; I doubt many DDs 
> will view
> your project favourably if you don't. Also, a word of advice: never 
> prioritise
> your own convenience over user experience. It portrays you as 
> selfish, and in
> this case stubborn, neither of which are a good look.
> 

Sorry about that particular line. I should have been more careful with 
my words. I wanted to say I'm open to change, but ended up disregarding 
the original reason.

We accepted his suggestion about dropping priority to 100 and setting 
the automatic upgrades setting to match buster-backports suite, so it 
was not the intention to be rude or disregard his suggestions 
completely. I have not shared this info here earlier because we have 
not implemented it yet.

> Now, for some constructive _technical_ advice. You don't need to 
> require
> rebuilds if you don't want to. I see two options for what you can do 
> to avoid
> that:
> 
> 1. Manually edit the .changes file, changing Distribution:, and then 
> re-sign.
>    You'll need to configure your DAK instance to not have the lintian 
> tag
>    distribution-and-changes-mismatch in its lintian.tags though (or 
> override it
>    in the package, but that's a bit weird and dangerous).
> 
> 2. Configure SuiteMappings in your dak.conf to redirect 
> buster-backports
>    uploads to buster-foo. That's it. You can present whatever name 
> you like to
>    users, and uploads to your service for buster-backports magically 
> end up in
>    the right place.
> 
> The second one is probably the better approach, though does come with 
> the risk
> that anyone can inject a signed -backports .changes file into your 
> service.
> That's generally frowned upon, but in this case you probably view it 
> as a
> feature. I'm in two minds about that, but that's ultimately up to you 
> running
> the service to decide.
> 

I think we will take the second approach and name it 
fasttrack-buster-backports (like we have buildd-buster-backports for 
incoming.debian.org).

> What frustrates me is that, had you responded more appropriately and 
> simply
> explained your motivations for doing what's currently implemented, we 
> could
> have skipped that whole first paragraph and gone straight to 
> solutions which I
> believe solve the problem for both sides. If you want people to be 
> more willing
> to help you, work with them, not against them, and especially don't 
> disregard
> their views. You may find solutions you didn't even know were 
> possible (or even
> thought to consider), like I suspect is the case here.
> 

Thanks to both of you for your suggestions and time.

> Jess
> 




More information about the Aptitude-devel mailing list